9
\$\begingroup\$

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.

\$\endgroup\$
  • 2
    \$\begingroup\$ Are you sure the PIC is expecting FAT32 and not FAT16? \$\endgroup\$ – Roger Rowland Jul 6 '15 at 12:32
  • \$\begingroup\$ @RogerRowland I tried with FAT16 as well but it gave me the same error. \$\endgroup\$ – user2344158 Jul 6 '15 at 12:37
  • \$\begingroup\$ This related post on Microchip's forums sounds similar. Have you seen that? \$\endgroup\$ – Roger Rowland Jul 6 '15 at 12:51
  • \$\begingroup\$ @RogerRowland yeah it is the same case I think. But it doesn't look like something is wrong... I will edit my question \$\endgroup\$ – user2344158 Jul 6 '15 at 13:38
  • \$\begingroup\$ It seems that the initializing is "wrapping" around and overwriting sector zero. Try a smaller length (1 GB?) \$\endgroup\$ – Guill Jul 11 '15 at 21:47
0
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.