FSInit() - "CE_BAD_PARTITION" [geschlossen]

Ich verwende einen PIC18F26K80 und einen XC8-Compiler. Ich versuche, eine SD-Karte zu initialisieren und eine Datei zu erstellen. Ich habe die SD-Karte unter Windows einfach so formatiert, dass sie ein „FAT32“-Dateisystem und eine „Zuordnungseinheitsgröße“ von 512 Byte hat. Die Kapazität der SD-Karte beträgt 2 GB. Ich verwende die MDD-Bibliothek aus der MLA Legacy-Version. Meine Hauptsache ist folgende:

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);
} 

Das Programm bleibt in der Funktion „FSInit()“ hängen und der Fehler, den ich von der Funktion erhalte, ist „CE_BAD_PARTITION“, was bedeutet „Der Boot-Datensatz ist fehlerhaft“.

Die Funktion "initIO()" ist die folgende:

//==============================================================================
// 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;
}

Die letzten beiden Bytes von Sektor 0 sind die Boot-Signatur und sie sollen 0x55 und 0xAA sein und das Bild, das ich beigefügt habe, bestätigt dies. Innerhalb der Funktion "LoadMBR" wird jedoch folgende Prüfung durchgeführt:

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

und obwohl die Bytes gleich sind, ist die erste Bedingung erfüllt und es kommt mit dem Fehler "CE_BAD_PARTITION" zurück.

Sind Sie sicher, dass der PIC FAT32 und nicht FAT16 erwartet?
@RogerRowland Ich habe es auch mit FAT16 versucht, aber es hat mir den gleichen Fehler gegeben.
Dieser verwandte Beitrag in den Foren von Microchip klingt ähnlich. Hast du das gesehen?
@RogerRowland ja, es ist der gleiche Fall, denke ich. Aber es sieht nicht so aus, als ob etwas nicht stimmt ... Ich werde meine Frage bearbeiten
Es scheint, dass die Initialisierung Sektor Null "umschließt" und überschreibt. Versuchen Sie es mit einer kleineren Länge (1 GB?)
Sie haben einen MBR-Dump bereitgestellt, der besagt, dass der Partitionstyp Ob (FAT32 mit CHS) ist, aber LBA-Informationen vorhanden sind und die LBA-Adressierung funktionieren sollte. Können Sie bitte einen Speicherauszug des Sektors bei LBA 0x00000080 hinzufügen, der voraussichtlich ein Bootsektor für die erste Partition ist. Je nachdem, was da ist, werden wir uns dann mit FAT befassen.
Sie müssen die Struktur untersuchen, auf die die Partitionsvariable zeigt, um zu beantworten, wo sich Signature0 und Signature1 befinden.
Der MOD hat eine relevante Antwort, die eher eine Abfrage ist, gelöscht, aber er hat dabei weitere Hilfe unterdrückt. dann später in einen Kommentar umgewandelt, gefolgt von keinem weiteren Dialog.. ...
Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da sie vom Fragesteller vier Jahre lang ohne Nachverfolgung einer Lösung aufgegeben wurde.

Antworten (3)

Sie stellen nicht genug von Ihrem Code bereit, um dies zu beheben, aber das Googeln nach den von Ihnen geposteten Fragmenten zeigt, dass es aus einem Teil einer FAT16-Bibliothek stammt.

Betrachten Sie Ihre gepostete Partitionstabelle

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 |................|

das sind die Flags 0x00, CHS 0/3/0 - CHS 238/231/57 LBA 128 - 3837952 und geben Sie 0xb ein

Typ 0xb zeigt eine FAT32-Partition an, also meine Vermutung ist beides

1) Ihr Code weigert sich, ihn anzusehen, weil er den falschen Partitionstyp hat, oder

2) unwahrscheinlich, Ihr Code ist verärgert, dass die CHS-Werte nicht mit den LBA-Werten übereinstimmen.

Versuchen Sie, diesen Partitionstyp auf 0x6 (FAT16) einzustellen, die Partitionstabelle mit vernünftigen CHS-Werten (oder Dummy-CHS-Werten) neu zu schreiben und die Partition als FAT16 zu formatieren.

Ich habe vor einiger Zeit so etwas ausprobiert und fand die Bibliotheken von Microchip schwierig. Es gibt ein FOSS FAT-System namens PetitFAT , das ich sehr einfach in Gang zu bringen fand. (Seine printf lib eignet sich auch hervorragend für kleine eingebettete Plattformen.) Hoffe, das hilft.

Machen Sie zunächst keine Weile () um FSINit () herum. Das ist einfach faul. Rufen Sie es auf, überprüfen Sie das Ergebnis und behandeln Sie es entsprechend, damit Ihr Programm nicht in einer unbekannten Endlosschleife hängen bleibt.

Zweitens, haben Sie sich die Definition für „FAT_GOOD_SIGN_0“ und „FAT_GOOD_SIGN_1“ angesehen, um sicherzugehen, dass sie 0x55 und 0xAA erwarten?

Drittens, haben Sie die Reihenfolge der Signaturbytes überprüft? FAT-32 sucht nach 0xAA55, nicht nach 0x55AA.

Dies wurde vor vier Jahren gefragt und von einem Benutzer aufgegeben, der seit zwei Jahren nicht einmal mehr auf der Website war. "Antworten" sind eigentlich nicht dazu gedacht, klärende Fragen zu stellen, da es unwahrscheinlich ist, dass Sie eine Antwort erhalten - realistischerweise ist das Problem selbst wahrscheinlich längst gelöst oder aufgegeben worden.
Eigentlich Chris, das ist ein bisschen eng. Die Leute schreiben immer noch benutzerdefinierte Treiber für eingebettete SD-Karten, ohne sich auf die möglicherweise fehlerhafte Bibliothek eines anderen zu verlassen, oder andere Bibliotheken sind zu groß oder aus anderen Gründen unzureichend. Dateisystemwissen ist eines der Dinge, die immer schwieriger zu bekommen sind, und fast jeder Informationsfetzen ist relevant. Was ich gepostet habe, hilft vielleicht nicht dem ursprünglichen Poster, aber es könnte jemand anderem helfen. Ich bin mir nicht sicher, warum Sie überhaupt kommentiert haben, da Sie der Konversation technisch nichts Nützliches hinzufügen.