STM32Cube_FW_F4_V1.18.0 + SDIO + FATFS R0.12c doesn't work

[Roberto Roman]

Posted on December 02, 2017 at 16:56

I tried to use the FAT file system with a SD card and the SDIO protocol, but with the v1.18.00 of stm32Cube for F4 MCU's doesn't work correctly, I discovered the next issues.

1.-  Inside of the FATFS configuration if the DMA tamplate is enable this module doesn't work

2.-   BSP_SD_Init() isn't called nowhere endded I need to call manually after  MX_FATFS_Init().

3.- DMA template is mandatory if FreeRTOS is enable.

Now, this issues didn't watch in the version v1.17.00 of 

stm32Cube for F4. The same programe is funcional in this version but not in the v1.18.00. 

Any idea regarding this topic? Is necessary to enable the DMA module to work with the protocol SDIO ?

[Standa Standa]

Posted on December 04, 2017 at 20:33

Hello,

my friend had same issue. I have noticed that after dma transfer complete interrupt (rx or tx) is fired, interrupt handler calls weak callback. Update to two calbacks below fixed the issue (in file stm32f4xx_hal_sd.c). I think somehow the linker uses weak implementations over generated ones (although I could not find 'strong' implementations in his generated code, thus I have acked it into weaks. Im not happy about it but it works and friend is happy ).

extern void BSP_SD_ReadCpltCallback();

extern void BSP_SD_WriteCpltCallback(); __weak void HAL_SD_TxCpltCallback(SD_HandleTypeDef *hsd){  /* Prevent unused argument(s) compilation warning */  UNUSED(hsd);

  /* NOTE : This function should not be modified, when the callback is needed,

            the HAL_SD_TxCpltCallback can be implemented in the user file   */  BSP_SD_WriteCpltCallback();                                        //BULLSHIT}__weak void HAL_SD_RxCpltCallback(SD_HandleTypeDef *hsd){  /* Prevent unused argument(s) compilation warning */  UNUSED(hsd);   /* NOTE : This function should not be modified, when the callback is needed,            the HAL_SD_RxCpltCallback can be implemented in the user file   */  BSP_SD_ReadCpltCallback();                                        //BULLSHIT}

[Amel NASRI]

Posted on December 07, 2017 at 11:30

Hello,

Please refer to the following if you have similar issue:

-

https://community.st.com/0D50X00009bMM8bSAG

-

https://community.st.com/0D50X00009XkXg5SAF

If you still have problems, don't hesitate to share them.

-Amel

[Marco1]

Posted on December 07, 2017 at 13:11

I have same problem, and i wrote it about one month ago...

[Marco1]

Posted on December 07, 2017 at 13:14

I have same problem, the functions

void BSP_SD_WriteCpltCallback()

{       osMessagePut(SDQueueID, WRITE_CPLT_MSG, osWaitForever);}

void BSP_SD_ReadCpltCallback()

{        osMessagePut(SDQueueID, READ_CPLT_MSG, osWaitForever);}

Are ignored from compiler, because no one call them.

[Amel NASRI]

Posted on December 07, 2017 at 14:02

Are generating code with CubeMX 4.23? Could you please share your .ioc file?

-Amel

[Marco1]

Posted on December 07, 2017 at 16:36

Yes, generated with 

CubeMX 4.23. I prefer to not share my .ioc, can i send you

in some private way ?

[John Craven]

Posted on December 07, 2017 at 19:24

Curious if anybody is having new FAT32 card issues with FATFS R0.12c?

I updated am old project to latest Cube 4.23 and my small 1gb and 2gb cards are working fine.

But a 32gb FAT32 card that previously worked with this project, is not working at all now.

When i try opening a file to write, i am getting FATFS error that there is no file system.

I have dug in deeper yet to see if something is failing before that point.

The 32gb card is working fine on PC and other devices. So its no the card.

This all worked without the suggested

https://community.st.com/0D50X00009bMM8bSAG

Adding the non RTOS change, did not fix my large card issue.

[Tesla DeLorean]

Posted on December 07, 2017 at 19:37

I've been using R0.13 for at least 6 months, with support for FAT32 and EXFAT, can't say I've experienced data loss with that, and have been using 32GB, 128GB and 200GB cards in data loggers.

Lack of file system suggests some issues with the MBR (Partition Table) or BPB sectors describing the volume. The newer FATFS releases have additional/different options related to multi volume support and long file names, which might also need review, I migrated from R0.09 to R0.13

The file system is somewhat fragile, it will not survive an SD/MMC layer that writes the wrong data to the wrong sectors, or retrieves the wrong data.

[John Craven]

Posted on December 07, 2017 at 20:05

First I know you don't use CUBE and HAL! LOL

I don't think i setup any special options with the large cards before. But that version of Cube is gone and cant go back and compare the default options that Cube generated.

But...I played with cube, and the FATFS ExFat option. It warned me that i also had to enable

USE_LFN (Use Long Filename) . Turning on both my card also didnt work. So LFN does make a difference.

I read that FAT/FAT32 were supported without options in 

http://elm-chan.org/fsw/ff/doc/config.html

 . Or at least i got that impression. Only mention of FAT32 is

FF_FS_NOFSINFO

0 to 3. If you need to know correct free space on the FAT32 volume, set bit 0 of this option, and

f_getfreefunction at first time after volume mount will force a full FAT scan. Bit 1 controls the use of last allocated cluster number.

ValueDescription

bit0=0Use free cluster count in the FSINFO if available.

bit0=1Do not trust free cluster count in the FSINFO.

bit1=0Use last allocated cluster number in the FSINFO to find a free cluster if available.

bit1=1Do not trust last allocated cluster number in the FSINFO.

Can see how either that would cause my issue.

I am more than willing to toggle on any FATFS options you suggest? 

[Tesla DeLorean]

Posted on December 07, 2017 at 21:50

Attaching ffconf.h

The error you're getting is more one of a structural failure in the sectors describing the partition or volume. You could breakpoint or step the code throwing the error. Most likely cause would be a write failure of some type corrupting the media content.

ST needs some code to thoroughly exercise the DISKIO layer interface and validates the read/write functionality over a broad range of blocks on the media.

________________ Attachments : ffconf.h.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyGT&d=%2Fa%2F0X0000000b5D%2F053o7PugBRdc2ph0kWdGsJBOPo6qG6AvfrWmtbXadno&asPdf=false