FSInit () - “CE_BAD_PARTITION” [cerrado]

9

Estoy usando un PIC18F26K80 y un compilador XC8. Estoy tratando de inicializar una tarjeta SD y crear un archivo. Simplemente he formateado la tarjeta SD en Windows para tener un sistema de archivos "FAT32" y un "tamaño de unidad de asignación" de 512 bytes. La capacidad de la tarjeta SD es de 2GB. Estoy usando la biblioteca MDD de la versión MLA Legacy. Mi principal es el siguiente:

FSFILE * file;
char sendBuffer[22] = "This is test string 1";

//**************************************************
// main function
//**************************************************

int main()
{
    initIO();
    LATBbits.LATB0 = 0;

    // Initialise SPI and SD-card
    while ( !MDD_MediaDetect() );

    // Initialize the device
    while ( !FSInit() );

    // Initialize 
#ifdef ALLOW_WRITES

    // Create a new file
    file = FSfopenpgm ( "FILE.TXT", "w" );
    if ( file == NULL )
        while(1);

    // Write 21 1-byte objects from sendBuffer into the file
    if ( FSfwrite ( (void *) sendBuffer, 1, 21, file ) != 21 )
        while(1);

    // Close the file
    if ( FSfclose ( file ) )
        while(1);

#endif

    LATBbits.LATB0 = 1;         //LED

    while(1) {}

    return (0);
} 

El programa se atasca dentro de la función "FSInit ()" y el error que obtengo de la función es "CE_BAD_PARTITION", que significa "El registro de arranque es malo".

La función "initIO ()" es la siguiente:

//==============================================================================
// void initIO( void );
//==============================================================================
// Sets the pins on the PIC to input or output and determines the speed of the
// internal oscilaltor
// input: none
// return: none
//==============================================================================
void initIO()
{
    OSCCON = 0x75;                  // Clock speed = 32MHz (4x8Mhz)

    TRISA = 0;
    TRISB = 0;
    TRISC = 0;

    TRISBbits.TRISB0 = 0;           //LED

    TRISCbits.TRISC3 = 0;           // set SCL pin as output
    TRISCbits.TRISC4 = 1;           // set RC4 pin as input
    TRISCbits.TRISC5 = 0;
    TRISAbits.TRISA5 = 0;
}

Los dos últimos bytes del sector 0 son la firma de arranque y están destinados a ser 0x55 y 0xAA y la imagen que incluí lo confirma. Sin embargo, dentro de la función "LoadMBR" se realiza la siguiente verificación:

if((Partition->Signature0 != FAT_GOOD_SIGN_0) || (Partition->Signature1 != FAT_GOOD_SIGN_1))
{
    FSerrno = CE_BAD_PARTITION;
    error = CE_BAD_PARTITION;
}
else
{
    ...
}

y aunque los bytes son iguales, la primera condición se cumple y vuelve con el error "CE_BAD_PARTITION".

usuario2344158
fuente
2
¿Estás seguro de que el PIC espera FAT32 y no FAT16?
Roger Rowland el
@RogerRowland También probé con FAT16 pero me dio el mismo error.
user2344158
Esta publicación relacionada en los foros de Microchip suena similar. ¿Has visto eso?
Roger Rowland el
@RogerRowland, sí, creo que es el mismo caso. Pero no parece que algo esté mal ...
Editaré
1
Estoy votando para cerrar esta pregunta como fuera de tema porque ha sido abandonada por el autor de la pregunta sin seguimiento hacia una solución durante cuatro años.
Chris Stratton

Respuestas:

1

No proporciona suficiente código para ayudar a depurar esto, pero buscar en Google los fragmentos que ha publicado muestra que proviene de parte de una biblioteca FAT16.

Mirando tu tabla de particiones publicada

000001c0 03 00 0b e7 39 ee 80 00 00 00 00 90 3a 00 00 00 | .... 9 .......: ... |
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ |

eso es banderas 0x00, CHS 0/3/0 - CHS 238/231/57 LBA 128 - 3837952 y tipo 0xb

tipo 0xb indica una partición FAT32, por lo que supongo

1) su código se niega a mirarlo porque tiene el tipo de partición incorrecto, o

2) poco probable, su código está molesto porque los valores de CHS no coinciden con los valores de LBA.

intente establecer ese tipo de partición en 0x6 (FAT16), reescribiendo la tabla de partición con valores CHS correctos (o valores CHS ficticios) y formateando la partición como FAT16.

James
fuente
0

Intenté algo como esto hace algún tiempo y encontré las bibliotecas de Microchip difíciles. Hay un sistema FOSS FAT llamado PetitFAT que me pareció muy fácil de poner en marcha. (Su printf lib también es ideal para pequeñas plataformas integradas). Espero que ayude.

danmcb
fuente
0

Primero, no hagas un rato () alrededor de FSINit (). Eso es solo vago. Llámelo y verifique el resultado y trátelo en consecuencia para que su programa no se atasque en un ciclo infinito desconocido.

En segundo lugar, ¿ha mirado la definición de 'FAT_GOOD_SIGN_0' y 'FAT_GOOD_SIGN_1' para asegurarse de que esperan un 0x55 y 0xAA?

Tercero, ¿ha verificado el orden de los bytes de firma? FAT-32 está buscando 0xAA55, no 0x55AA.

GSLI
fuente
Esto fue solicitado hace cuatro años y abandonado por un usuario que ni siquiera ha regresado al sitio en dos años. En realidad, no se supone que las "respuestas" se usen para hacer preguntas aclaratorias, ya que es poco probable que obtenga una respuesta; de manera realista, el problema en sí mismo probablemente se haya resuelto o abandonado hace mucho tiempo.
Chris Stratton el
En realidad Chris, eso es un poco estrecho. La gente todavía está escribiendo controladores personalizados para tarjetas SD para embebidos, sin depender de la biblioteca posiblemente defectuosa de otra persona u otras bibliotecas son demasiado grandes o por alguna otra razón inadecuada. El conocimiento del sistema de archivos es una de esas cosas que es cada vez más difícil de encontrar, y casi cualquier fragmento de información es relevante. Lo que publiqué puede no ayudar al póster original, pero puede ayudar a alguien más. No estoy seguro de por qué incluso comentaste, ya que técnicamente no agregas nada a la conversación de ninguna manera útil.
GSLI