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 ?

[Tesla DeLorean]

Posted on December 02, 2017 at 19:22

Well DMA is highly desirable if you want to hit 10MBps numbers AND do useful work

[Roberto Roman]

Posted on December 02, 2017 at 19:50

The problem is that DMA is mandatoty if freeRTOS is enable, if I disable the DMA stm32cube launch a error 

[Tesla DeLorean]

Posted on December 02, 2017 at 20:20

I've got a number of successful projects on the F4 series parts using SDIO+DMA, so it's not inherently a problem, but rather a software choice issue.

[smeric]

Posted on December 03, 2017 at 22:00

I have also has same problem. when I try with with STM32Cube_FW_F4_V1.18.0 + SDIO + FATFS R0.12c SDID 1bit is not work but 1.12 is working so I did not understand why ? anyone can do and share a base project ? my proect is giving hadware error when f_open function calling. 

best regards.

[Roberto Roman]

Posted on December 03, 2017 at 22:05

Do you want to use DMA or no ? What platform are you using ?

[smeric]

Posted on December 03, 2017 at 22:26

with DMA, Keil or SW4STM32 ( I prefer ), I have stm32f4 discovery board and stm32f429 DISCO 

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

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

function 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? 

[Roberto Roman]

Posted on December 08, 2017 at 03:34

[Solution]

-----------------------------------------------------------   main

.c     

-----------------------------------------------------------

Call this function before  MX_FATFS_Init

 

BSP_SD_Init();

>>>>>>>>>>>>

This part if just if you want to use FATfs + FreeRtos

Create a queue with the name of

SDQueueID

example:

osMessageQDef(SDQueueID_, 16, uint32_t);

SDQueueID = osMessageCreate(osMessageQ(SDQueueID_), NULL);

-----------------------------------------------------------

sd_diskio.c 

-----------------------------------------------------------

put the SD QueueID declaration how to extern:   

extern

osMessageQId SDQueueID;

-----------------------------------------------------------sd_diskio.c 

-----------------------------------------------------------

Delete the static in the 

SDQueueID declaration;  

static

 osMessageQId SDQueueID;

>>>>>>>>>>>> 

//void BSP_SD_WriteCpltCallback()

void HAL_SD_TxCpltCallback(SD_HandleTypeDef *hsd)

{

osMessagePut(SDQueueID, WRITE_CPLT_MSG, osWaitForever);

}

//void BSP_SD_ReadCpltCallback()

void HAL_SD_RxCpltCallback(SD_HandleTypeDef *hsd)

{

osMessagePut(SDQueueID, READ_CPLT_MSG, osWaitForever);

}

[Marco1]

Posted on December 08, 2017 at 17:15

Work fine, many thanks !!

[Feion Nin]

Posted on February 06, 2018 at 19:09

I have been annoy by this problem for several days, and thank Roman very very much for that after i follow Roman's solution I fix my problem and the SD card with FATFS can work with dma in RTOS correctly.In addition, I think that the SD initialization code and queue creating code should add to the sd_diskio.c -> DSTATUS SD_initialize(BYTE lun), And the key is modify two function name:

void HAL_SD_TxCpltCallback(SD_HandleTypeDef *hsd)

a

nd

void HAL_SD_RxCpltCallback(SD_HandleTypeDef *hsd)

.

[Amel NASRI]

Posted on February 26, 2018 at 10:52

Hello,

The issue that is still being faced even with last STM32CubeMX version (4.24) will be reported internally again.

For those who look for a complete solution, please refer to guidelines suggested by

bardeenlai

‌ in

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

.

-Amel

[Steffen M]

Posted on April 09, 2018 at 23:08

Hello,

it is sufficient to remove the __weak in the bsp_driver_sd.h file for BSP_SD_ReadCpltCallback and BSP_SD_ReadCpltCallback. The good thing is that this is persistent even when updating the project with CubeMX. The __weak in the header file is a known problem for quite a few frameworks.

st.mcu

‌

When will CubeMX be updated to fix this issue? I took me quite a while to figure it out;

found that thread just when I discovered the problem by myself ... really annyoing.

As this is described for F4 it, I had it with STM32L4R9I.

Best regards

Steffen