STM32CubeMX SDIO F4

[joe]

Posted on June 03, 2014 at 18:01

Hi, I've been trying to get SDIO working on the STM32F4 Discovery board. I've wired up the SD card and created a basic project using CubeMX.

The MX_SDIO_SD_Init() function completes successfully but I cannot get the HAL_SD_ReadBlocks function to work. I get SD_ILLEGAL_CMD when the SD_CMD_SET_BLOCKLEN command is sent. I've lowered the SDIO clock speed by setting the SDIO_TRANSFER_CLK_DIV define to 0x50 ( 0x76 is 400kHz ) but I'm still have issue. Anyone have this working?

[joe]

Posted on June 05, 2014 at 13:10

Just a bit of an update. Although I though I was lowering the clock speed of the SD clock by changing the SDIO_TRANSFER_CLK_DIV define. It was actually being set to 24Mhz before leaving the HAL_SD_Init function. This happens right before the return at SDIO_Init(hsd->Instance, hsd->Init);

The hsd->Init struct contains all 0's so the ClockDiv field is getting set to 0, so clock is being set to 48Mhz/(0+2) = 24Mhz.

I added the line hsd->Init.ClockDiv = SDIO_INIT_CLK_DIV; (Line 370) just before the SDIO_Init at the end of the HAL_SD_Init function to keep the clock speed at 400kHz. I also have SDIO_TRANSFER_CLK_DIV (stm32f4xx_ll_sdmmc.h) set to 0x76 ( 400kHz ) for my testing also.

All operations seem to be now working at this speed, no more CRC or timeout errors. I have a temporary SD card wired to the F4 discovery board and my wiring may be too long but at least I can work from this working low clock speed and figure out the rest. Hope this helps someone, I've been a few days trying to figure out why it wasn't working.

[joe]

Posted on June 06, 2014 at 19:33

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32Cube%20%2B%20F4-Discovery%20%2B%20FatFS&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=153]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FSTM32Cube%20%2B%20F4-Discovery%20%2B%20FatFS&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=153

Just discovered the above post from elaske which seems to address the issues/bugs in HAL driver. I has allowed me to get my project up and running and should be a sticky somewhere.

[egarcia]

Posted on February 13, 2016 at 01:31

Dear denehan.joe:

Words cannot describe how your post has helped us! It's eigth at night on a Friday, and we were working on a SD bug that has haunt us for days. I made your change and voila!!!

Thank you very much, I owe you a beer/non-alcoholic beverage of your choice!

Cheers,

-Ed

[askari.nima]

Posted on February 13, 2016 at 17:59

[schelven]

Posted on February 20, 2016 at 23:06

Hi,

I have it working after some struggles.. I added pull up resistors of 47K to D0-D3 and the CMD line

[stock239955]

Posted on February 25, 2016 at 17:13

I know the original post is quite old, but I'm having exactly the same problem with the latest STM32F7-Discovery board. I can compile and run the FatFs_uSD example (make file system, write file, read file, compare) from the Cube package and it works fine with the SD card running at full speed (24MHz).

However, after transplanting the same test code into my own program, with board/driver setup taken care of by CubeMX, I cannot get the card to run at full speed. It fails with an error at the format/make file system stage, specifically when disk_write is called. If I reduce the SDMMC_CK rate by increasing the clock divider, the code will eventually run at speeds of 6MHz or less.

I've modified the setup routines to exactly replicate the clock tree and GPIO settings from the example, but to no avail. I am baffled as to what else can be different.

The only obvious thing is that the example uses stm32746g_discovery_sd.c  whilst CubeMX has used bsp_driver_sd.c for my program, but I am yet to spot any difference in what they actually do.

Has anyone else encountered or, better, resolved this problem? I'm going mad here!

Thanks,

Steve

[petr239955]

Posted on February 26, 2016 at 00:33

Hi,

I have similar experience. My test of SD cards is successful only for

one of the four

memory cards

.

I tried to

reduce SDMMC_CK to

400 kHz

or to use non-

DMA

mode, no success.

I use

our own

PC

B,

I have one board

with

STM32F407ZGT6

and second with

STM32F746

ZGT6.

The STM32F407

works properly

.

I

wrote a

program

using

STM32Cube

MX

4.12.0 and STM32Cube_FW_F7_V1.3.1. I use testing procedure from FatFs_uSD example.

Could

someone

from the CubeMX team

to check

the function

of FatFs_uSD example

using program

which is generated

STM32CubeMX ?

Petr

[stock239955]

Posted on February 29, 2016 at 11:09

I dug around on this forum a bit more, and a summary seems to be:

1. Once the SDIO write is enabled, the FIFO needs data very quickly. However, it is not possible to preload the FIFO and underrun errors happen if you do not get enough data into it fast enough.

2. The obvious cure is to enable Hardware Flow Control, which holds back the write process if there is insufficient data available, but this feature is flawed in the F4xx devices and the errata sheets states that it should not be used. It is not mentioned in the errata for the F7xx devices which I am using. I turned on Flow Control and was able to successfully execute the test code with the SDIO clock set at full speed (24MHz), which had until then stubbornly refused to work.

3. Some people say that the underrun problem does not occur if the SDIO is fed using DMA; others seem to still have problems with DMA. I am using non-DMA routines, but so does the ST FatFs_uSD example code (which works fine).

4. I have no idea why the ST example runs correctly on my Disco board whilst nominally the same code embedded in my own program does not. I have replicated the example scenario as closely as I can and the debugger window indicates that both the configuration registers and the parameter values entering the HAL_SD_WriteBlocks routine are identical. I can only assume that something, somewhere is ''distracting'' the processor at the critical moment, but what it is is not apparent (I have disabled everything non-essential).

 The most useful post I found was this one:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/SDIO%2bDMA%20FIFO%20Error%20%28TX%20Underrun%29%20F4%20STM32F417ZGT6&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=273

...and my thanks go to the other engineers who investigated and bothered to post their findings to act as a pointer.

I'm going to press ahead with Flow Control enabled and see where it gets me!

Cheers,

Steve L.

[petr239955]

Posted on March 04, 2016 at 16:20

Hi Steve,

today I tried the FATFS demo example for the Open746I-C board from Waveshare company

http://www.waveshare.com/wiki/Open746I-C

. It is generated by STM32CubeMX and 

based on ST example

. I have the same result as with my program, only one my SD card is

functional

.

Please

can someone

from

ST

company

check the

function

of

SDIO

and

FATFS

libraries for

STM32F7xx

by

STM32CubeMX

generated project

.

Our

company would like

to use

these

microcontrollers

for

datalogger,

but with a

malfunction of the

SD

card

it

is

impossible.

Petr