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.
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.
Roger Rowland
Benutzer2344158
Roger Rowland
Benutzer2344158
Guill
Anonym
Ayhan
Tony Stewart EE75
Chris Stratton