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.

[Mohammad A]

Posted on September 10, 2017 at 21:10

I have followed this tutorial:

https://www.youtube.com/watch?v=FQ_8AmQbDgM

  and also

Fat Filesystem - Mastering STM32 by Carmine Noviello. What I have done is following the tutorial step by step, but I could not reproduce expected results.

I just wanted to make sure there is no another new born bug in HAL.

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

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