STM32F4 FatFs middleware problem with f_open();

[suilarso]

Posted on December 24, 2015 at 02:34

Would like to know if anyone comes across pointer crash when using f_open()?

Background:

Our project's configuration include FatFs and USB Host, and the LSE and HSE are 32.7KHz and 8MHz respectively. 

The media used for FatFs is 1GB USB thumbdrive formatted with FAT16.

I was able to successfully mount the device in our project, but faced problem when I tried to create a file with f_open(&filePtr, (const TCHAR *) filename, FA_OPEN_ALWAYS | FA_WRITE) function. The filePtr after the completion of f_open() function call became corrupted even though the f_open() function return FR_OK. I stepped through the code in debug mode and saw the pointer corruption occurred toward the end of f_open() function.

Would appreciate if anyone would like to share a solution for the above problem.Thanks & Regards #fatfs #f_open #usb

[Osto]

Posted on December 26, 2015 at 17:15

Hi,

Whats the name of the file? Do you want to create a new file or truncate an existing file? Does the file exist?

[Tesla DeLorean]

Posted on December 26, 2015 at 17:50

Make sure you have an adequate stack allocation.

[suilarso]

Posted on December 28, 2015 at 00:49Hi,I am creating a new file with filename ''0:/result_151223_131515.csv''.Thanks & Regards.Suilarso Japit

[suilarso]

Posted on December 28, 2015 at 00:55Hi,How do we adjust stack and heap allocation?I am compiling my application in AC6 environment.Thanks & Regards,Suilarso Japit

[Osto]

Posted on December 28, 2015 at 16:42

Hi,

Is long file name enabled? If you are using dynamic allocation then a 512byte array will be created from heap else it have to be available on stack. If you are using FREERTOS, the standard stack size is not enough for using FATFS. You need to give the task ~2KB of stack.

[Tesla DeLorean]

Posted on December 28, 2015 at 19:30

GNU/GCC systems typically define the stack in the linker script, start there, or become more familiar with your chosen tools and settings. The stack is likely parked at the top of SRAM, and very large.

Start with a simple 8.3 file name, this will work whether you have LFN (long file name) support, or not. When debugging, look at what's happening as you step through. Keep an eye on the memory, the stack, and where in the source you are. You have all the source so it should make it significantly easier to pin down the problem.