FSInit () - „CE_BAD_PARTITION” [zamknięty]

9

Używam PIC18F26K80 i kompilatora XC8. Próbuję zainicjować kartę SD i utworzyć plik. Po prostu sformatowałem kartę SD w systemie Windows, aby mieć system plików „FAT32” i „rozmiar jednostki alokacji” 512 bajtów. Pojemność karty SD wynosi 2 GB. Korzystam z biblioteki MDD z wersji MLA Legacy. Moje główne to:

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

Program utknął w funkcji „FSInit ()”, a błąd, który otrzymuję z funkcji, to „CE_BAD_PARTITION”, co oznacza „Niepoprawny rekord rozruchowy”.

Funkcja „initIO ()” jest następująca:

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

Ostatnie dwa bajty sektora 0 są sygnaturą rozruchową i powinny to być 0x55 i 0xAA, a obraz, który podałem, to potwierdza. Jednak w ramach funkcji „LoadMBR” dokonuje się następującej kontroli:

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

i chociaż bajty są takie same, pierwszy warunek jest spełniony i zwraca błąd „CE_BAD_PARTITION”.

użytkownik2344158
źródło
2
Czy na pewno PIC oczekuje FAT32, a nie FAT16?
Roger Rowland,
@RogerRowland Próbowałem również z FAT16, ale dał mi ten sam błąd.
user2344158
Podobny post na forach Microchip brzmi podobnie. Widziałeś to?
Roger Rowland,
@RogerRowland tak, myślę, że to ten sam przypadek. Ale nie wygląda na to, że coś jest nie tak ...
Zedytuję
1
Głosuję za zamknięciem tego pytania jako nie na temat, ponieważ pytanie zostało porzucone przez pytającego bez kontynuacji rozwiązania przez cztery lata.
Chris Stratton

Odpowiedzi:

1

Nie podajesz wystarczającej ilości kodu, aby pomóc w debugowaniu tego, ale przeglądanie opublikowanych fragmentów pokazuje, że pochodzi ono z części biblioteki FAT16.

Patrząc na opublikowaną tabelę partycji

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

to flagi 0x00, CHS 0/3/0 - CHS 238/231/57 LBA 128 - 3837952 i wpisz 0xb

typ 0xb oznacza partycję FAT32, więc zgaduję, że tak

1) Twój kod nie chce na to patrzeć, ponieważ ma niewłaściwy typ partycji lub

2) mało prawdopodobne, że kod jest zdenerwowany, że wartości CHS nie pasują do wartości LBA.

spróbuj ustawić ten typ partycji na 0x6 (FAT16), przepisując tabelę partycji za pomocą rozsądnych wartości CHS (lub fałszywych wartości CHS) i sformatując partycję jako FAT16.

James
źródło
0

Jakiś czas temu próbowałem czegoś takiego i okazało się, że biblioteki Microchip są trudne. Istnieje wywołanie systemowe FOSS FAT PetitFAT , które bardzo mi się podobało . (Jego printf lib jest także świetny dla małych platform osadzonych.) Mam nadzieję, że to pomaga.

danmcb
źródło
0

Po pierwsze, nie rób przez chwilę () wokół FSINit (). To po prostu leniwe. Zadzwoń, sprawdź wynik i odpowiednio go obsłuż, aby Twój program nie utknął w nieskończonej, nieznanej pętli.

Po drugie, czy sprawdziłeś definicję „FAT_GOOD_SIGN_0” i „FAT_GOOD_SIGN_1”, aby upewnić się, że oczekują wartości 0x55 i 0xAA?

Po trzecie, czy sprawdziłeś kolejność bajtów podpisu? FAT-32 szuka 0xAA55, a nie 0x55AA.

GSLI
źródło
Zostało to zadane cztery lata temu i porzucone przez użytkownika, który nawet nie wrócił na stronę od dwóch lat. „Odpowiedzi” tak naprawdę nie powinny być używane do zadawania wyjaśniających pytań, ponieważ jest mało prawdopodobne, że otrzymasz odpowiedź - realistycznie, sam problem prawdopodobnie już dawno został rozwiązany lub porzucony.
Chris Stratton,
Właściwie Chris, to trochę wąskie. Ludzie nadal piszą niestandardowe sterowniki dla kart SD dla osadzonych, nie polegając na czyjejś uszkodzonej bibliotece lub innych bibliotekach są zbyt duże lub z innego powodu nieodpowiednie. Znajomość systemu plików jest jedną z tych rzeczy, która staje się trudniejsza do zdobycia, i prawie każdy fragment informacji jest istotny. To, co opublikowałem, może nie pomóc oryginalnemu plakatowi, ale może pomóc komuś innemu. Nie jestem pewien, dlaczego nawet skomentowałeś, ponieważ nic nie dodajesz do rozmowy w żaden przydatny sposób.
GSLI