FAT FS

[jdcowpland]

Posted on November 01, 2013 at 09:51

Hi,

Can anyone give me some help/advice on how to go about implementing Chan's FAT FS? I'm using MikroC Pro for ARM as my toolchain so things are going to be little bit different from most of the toolchains used on here, but principles should still be the same. Do I need to edit any of his functions, what ones do I need to call from my own code etc?

[chen]

Posted on November 01, 2013 at 11:55

Hi

The code is well documented and it tells you where you have to provide code. The FAT FS software provides the functions for fopen etc to read/write to FAT32 partitioned memory cards. You have to provide the low level driver to access the memory card. If I remember correctly, the driver layer is POSIX compliant. The driver has to provide read, write and control functions with absolute addressing in the memory card.

[Tesla DeLorean]

Posted on November 01, 2013 at 12:09

One modifies the access functions in DISKIO.C to conform with the drive(s) and hardware abstractions thereof.

[jspika]

Posted on November 11, 2013 at 15:05

Hi,

I was using Chan´s FATFS and this diskio https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/27480/diskio.c  and everythinkg was working ok.

[jdcowpland]

Posted on January 20, 2014 at 12:49

Hi again,

I'm now using FatFS and it's all working well apart from one issue I currently have. I have one function which mounts my volume, and another which creates and writes my file. My file creation function looks like this, but when I examine the file on my pc, it contains the bytes 0x00,0x00,0x3f,0x Any idea why the first two bytes are being overwritten as 0x00?

void WRITE_FILE(void){
uint16_t bytesWritten;
uint8_t data[]={0x00,0x54,0x3f,0x12};
f_open(&file, ''Test.ddd'', FA_CREATE_ALWAYS | FA_WRITE);
f_write(&file,data,sizeof(data), (void *)&bytesWritten);
f_close(&file);
}

[Tesla DeLorean]

Posted on January 20, 2014 at 15:03

In disk_write() output the parameters passed, and the first 8 bytes of the sector. If you see your full data pattern here, then the problem is with your SDIO code.

[chen]

Posted on January 20, 2014 at 15:05

Hi

I am not 100% certain but it could be due to memory alignment. ''

uint8_t data[]={0x00,0x54,0x3f,0x12};

'' can be aligned to any byte boundary.

''(void *)&bytesWritten)

'' is forcing the address onto a 32bit boundary.

[jdcowpland]

Posted on January 20, 2014 at 18:11

Clive: I'm using the USB code provided by STM for the firmware update so it's unlikely to be anything on that side of the fat stuff. I'll take a look a the parameters being passed tomorrow though and let you know if they show anything.

Sung: If that were the case, how would I go about fixing it?

[chen]

Posted on January 20, 2014 at 18:33

Hi

''Sung: If that were the case, how would I go about fixing it?'' ''

uint8_t data[]={0x00,0x54,0x3f,0x12};

'' With this trivial case - the compiler can put the data anywhere it likes. The compiler has packed the code in as efficiently as possible. http://en.wikipedia.org/wiki/Data_structure_alignment You will probably not have an issue with RAM. You can create a buffer of type int (or any other variable type that is aligned to 4bytes) then cast a uint8_t pointer onto that buffer.