FatFS f_write does not work

[Mohammad A]

Posted on September 09, 2017 at 00:21

Function f_write doesn't work correctly to write on SD card. Actually it calls a series of other function and one of them is HAL_SD_WriteBlocks which puts the mcu into

Default_Handler:

Infinite_Loop: b Infinite_Loop

This is the code I have used to write a test string into a file:

 FATFS fs;
 FIL file;
 uint8_t string[]='string';
 UINT counter;
 if(f_mount(&fs,SD_Path,1)==FR_OK){
 if(f_open(&file,'root_f1',FA_WRITE|FA_CREATE_ALWAYS)==FR_OK){
 f_write(&file,string,(UINT)sizeof(string),&counter);
 }
 }
 f_close(&file);
 f_mount(NULL,'0:',1);�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

I have tried enabling and disabling every interrupts or DMA, changing sd clock, bus width. Does not make difference.

This is while reading from the SD Card works.

CubeMX ver: 4.0

CubeF7 ver: 1.7.0

MCU: STM32F746

#bug #stm32 #f

[Mohammad A]

Posted on September 09, 2017 at 01:29

Ok, I have commented out Infinite_loop and then, debugger goes into this function:

HAL_StatusTypeDef SDMMC_WriteFIFO(SDMMC_TypeDef *SDMMCx, uint32_t *pWriteData)
{
 /* Write data to FIFO */
 SDMMCx->FIFO = *pWriteData;
 return HAL_OK;
}�?�?�?�?�?�?�?

in the next step, it shows a message which says No source available for '__libc_init_array() at 0x8005332'. and the next step goes back to the SDMMC_WriteFIFO again.

[Mohammad A]

Posted on September 09, 2017 at 01:44

update 2:

I can easily read and write raw data on sd card using only HAL_SD_WriteBlocks and HAL_SD_ReadBlocks

[Tesla DeLorean]

Posted on September 10, 2017 at 00:10

You'll need to determine what IRQ Handler isn't set up right. If you are using C++ remember that it mangles names.

Either you haven't got a Handler or it is miss named.

[Mohammad A]

Posted on September 10, 2017 at 06:18

I have not enabled any additional interrupt so I don't expect any IRQ Handler to be set up. As I have explained, there must be a problem in FatFS because I can write data in raw mode.

Also, for setting up a project to work with fatfs, I have followed working tutorials available online which I expect them to work for me too, but they don't.

[Tesla DeLorean]

Posted on September 10, 2017 at 20:50

FATFS or more likely the layer below it.

No idea what tutorial you followed, or what code you created. Make sure you have allocated an adequate stack, and that FATFS isn't passing down buffers that don't have alignment suitable for DMA, etc.

Code in diskio.c would be where you look for interfacing into layers below.

[Gabriele Caletti]

Posted on September 13, 2017 at 10:40

I'm actually experiencing the same problem with some SD cards (ex. a 2GB Sandisk). I have an application that is compiled for both F4 and F2 uC that needs to read some files and write a log file to the SD card. I'm using the SDIO interface with the latest HAL (v1.16) for F4 and  (v1.6) for F2 and FatFS 1.12c.

On the F2, the application has been migrated from Std Periheral Library to the HAL. The 'faultly' SD card is working fine with the old application (Std Periph Lib) but no longer with the newest HAL version.

I tried to implement it with both DMA or polling, but in both cases the HAL_SD_WriteBlocks() or HAL_SD_WriteBlocks_DMA() are not working correctly.

I'm also taking into account the fact that the HAL might have a bug...

[Mohammad A]

Posted on September 13, 2017 at 17:57

Thanks for sharing your experience.

For me I don't think it's a bug related to HAL because I can write using HAL functions, but when it comes to integrating fatfs into work, program gets stuck into a infinite loop.

[Gabriele Caletti]

Posted on September 14, 2017 at 16:28

I agree, I'm not sure it's a HAL issue. What I'm saying is that with the new HAL, the SDIO/FatFS seem to be less stable than before. In my case, with the following 2 changes the writing to the SD card works fine:

• set the compiler optimization off, i.e. -O0
• at SD card initialization comment out the step to move to a 4-bit data bus, i.e. HAL_SD_ConfigWideBusOperation(&uSdHandle, SDIO_BUS_WIDE_4B)

In my opinion, those changes as well as the ones reported by other users should not impact the SD wrinting functionality. This is why I have a bad feeling about the robustness of the HAL/FatFS combination.

[Dariusz Zieniewicz]

Posted on September 14, 2017 at 14:48

In my case, when FIL file; variable is placed as local, the CPU going to HardFault_Handler.

But when I place it as global, working very well.

[Tesla DeLorean]

Posted on September 14, 2017 at 16:40

Consider if your stack is large enough for the structures you are allocating on it. Does it fault if it is a static auto/local variable? How big is the stack, and how much of it is being used.

Look specifically at what is faulting, the CPU is capable of generating a lot of useful information about how/why it ended up there, a while(1) loop isn't going to be very informative.