FSInit() - "CE_BAD_PARTITION"

Question

I am using a PIC18F26K80 and an XC8 compiler. I am trying to initialise an SD card and create a file. I have simply formatted the SD card on Windows to have a "FAT32" file system and an "Allocation unit size" of 512 bytes. The capacity of the SD card is 2GB. I am using the MDD library from the MLA Legacy version. My main is the following:

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

The program gets stuck inside the function "FSInit()" and the error I get from the function is "CE_BAD_PARTITION", which means "The boot record is bad".

The "initIO()" function is the following:

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

The last two bytes of sector 0 are the boot signature and they are meant to be 0x55 and 0xAA and the picture I included confirms that. However, inside the function "LoadMBR" the following check is made:

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

and although the bytes are the same the first condition is met and it returns with the "CE_BAD_PARTITION" error.

@RogerRowland I tried with FAT16 as well but it gave me the same error. — user2344158, Jul 06 '15 at 12:37
[This related post](http://www.microchip.com/forums/m350838.aspx) on Microchip's forums sounds similar. Have you seen that? — Roger Rowland, Jul 06 '15 at 12:51
@RogerRowland yeah it is the same case I think. But it doesn't look like something is wrong... I will edit my question — user2344158, Jul 06 '15 at 13:38
It seems that the initializing is "wrapping" around and overwriting sector zero. Try a smaller length (1 GB?) — Guill, Jul 11 '15 at 21:47
You must examine the struct which partition variable points to, for answering where are Signature0 and Signature1 located. — Ayhan, Dec 17 '16 at 08:24
You provided MBR dump, which says partition type Ob (FAT32 with CHS) but LBA information is there and LBA addressing should work. Can you please add dump of the sector at LBA 0x00000080 which is expected to be a boot sector for first partition. Depending on what is there, we will then look into FAT. — Anonymous, Oct 17 '16 at 11:33
the MOD deleted a relevant answer which is more a query but he suppressed further help in doing so. then later converted it a comment followed by no further dialog.. ... — Tony Stewart EE75, May 24 '17 at 15:48
I'm voting to close this question as off-topic because it has been abandoned by the asker without follow-up towards a solution for four years. — Chris Stratton, Aug 01 '19 at 22:31

score 1 · Answer 1 · answered Jan 19 '19 at 20:11

You don't provide enough of your code to help debug this, but googling for the fragments you have posted show it coming from part of a FAT16 library.

Looking at your posted partition table

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

that's flags 0x00, CHS 0/3/0 - CHS 238/231/57 LBA 128 - 3837952 and type 0xb

type 0xb indicates a FAT32 partition, so my guess is either

1) your code is refusing to look at it because it has the wrong partition type, or

2) unlikely, your code is upset that the CHS values don't match the LBA values.

try setting that partition type to 0x6 (FAT16), rewriting the partition table with sane CHS values (or dummy CHS values), and formatting the partition as FAT16.

score 0 · Answer 2 · answered May 24 '18 at 21:34

0

I tried something like this some time ago and found Microchip's libraries difficult. There is a FOSS FAT system call PetitFAT which I found very easy to get going. (His printf lib is also great for small embedded platforms.) Hope that helps.

answered May 24 '18 at 21:34

danmcb

6,009
14
29

score 0 · Answer 3 · answered Aug 01 '19 at 22:05

0

First, don't do a while() around FSINit(). That's just lazy. Call it and check the result and handle it accordingly so your program doesn't get stuck in an endless unknown loop.

Second, have you looked at the define for 'FAT_GOOD_SIGN_0' and 'FAT_GOOD_SIGN_1' to be sure they are expecting a 0x55 and 0xAA?

Third, have you checked the order of the signature bytes? FAT-32 is looking for 0xAA55, not 0x55AA.

answered Aug 01 '19 at 22:05

GSLI

116
4

This was asked four years ago and abandoned by a user who has not even been back to the site in two years. "Answers" aren't really supposed to be used to ask clarifying questions, at it is unlikely you will get a response - realistically, the problem itself has probably been long since solved or abandoned. – Chris Stratton Aug 02 '19 at 02:17
Actually Chris, that's a little narrow. People are still writing custom drivers for SD cards for embedded, not relying on someone else's possibly buggy library or other libraries are too big or for some other reason inadequate. Filesystem knowledge is one of those things that is getting harder to come by, and almost any scrap of information is relevant. What I posted may not help the original poster, but it might help someone else. I'm not sure why you even commented, since you are adding nothing to the conversation technically in any useful way. – GSLI Aug 02 '19 at 16:48

FSInit() - "CE_BAD_PARTITION"

3 Answers3