STM32L4 + SD + STM32CubeMX v5.0.0: SD clock speed during call to SDMMC_CmdSendSCR (as part of switch to 4-bit bus) is too fast for many SD cards

[Steve Melnikoff]

The function BSP_SD_Init() is called once the basic SD card initialisation is complete, and after the SD clock speed has switched from 400 kHz(*) to full speed.

If the bus has been configured in Cube to use 4-bit mode, the following call chain occurs, which ultimately reads the SD card's SCR register, to check if it supports 4-bit mode:

BSP_SD_Init() -> HAL_SD_ConfigWideBusOperation() -> SD_WideBus_Enable() -> SD_FindSCR() -> SDMMC_CmdSendSCR()

We found that different cards respond differently to this command at full clock speed. Some work most of the time, but sometimes fail. Some respond to the command without error - but report that the register contents (stored in scr) are zero. And some never respond to the command, causing the code to enter the timeout loop - which is unfortunate because SDMMC_DATATIMEOUT is set to (essentially) forever, so the code gets stuck here.

Although the SD spec (if we've understood it correctly) seems to suggest that it should be fine to read the SCR register at any speed, this doesn't seem to be true in practice. So, we modified BSP_SD_Init() to reduce the clock speed to 400 kHz before the call to HAL_SD_ConfigWideBusOperation() - and this solved the problem completely.

It wasn't necessary to change the clock speed back again ourselves, as this happens in HAL_SD_ConfigWideBusOperation() if the SCR read is successful.

So we recommend that ST change the library code, whether in the default BSP_SD_Init() or elsewhere, so that the SCR read occurs at 400 kHz.

(*) Actually, the initialisation SD clock speed is only set to 400 kHz if the SD peripheral clock is 48 MHz, as the library doesn't check what its true value is. Hence SDMMC_INIT_CLK_DIV is fixed at 0x76, giving a divider value of 120. All this means is that if you're using a slower peripheral clock, then the initialisation clock speed will be below 400 kHz. This is harmless, but means that SD setup may take slightly longer.

[Imen.D]

Hello @Steve Melnikoff​ ,

Your issue has been raised for check and analysis.

We will come back to you soon with update.

Regards,

Imen

[Steve Melnikoff]

Thank you.

Is there any word on whether any of the 4 other bugs I've reported, relating to the SD card drivers, will be reviewed at some point?

[Matthew Staben]

0x76 is not 120.

I noticed that SDMMC_INIT_CLK_DIV is set to 0x76 which does not evenly divide into 48Mhz as does 0x78 (120) making 400Khz.

[Tesla DeLorean]

RM0386

Bits 7:0 CLKDIV: Clock divide factor This field defines the divide factor between the input clock (SDIOCLK) and the output clock (SDIO_CK): SDIO_CK frequency = SDIOCLK / [CLKDIV + 2]

[Matthew Staben]

Got it. Thanks for pointing that out.

[Tesla DeLorean]

Couple of L4 parts where this is unhelpfully different, or the clock can pull from multiple sources.​

[Imen.D]

Hello,

The SD specification allow to perform the SEND_SCR command in Data Transfer Mode. It means that the allowed speed is authorized to 25 MHz.

We perform tests with 7 several SD cards from 4 different manufacturers with different capacity without any issue. What are the exact reference of these faulty cards (Manufacturer, Capacity, Class, ...) ?

If there is some communication issue between the host and the card, it is recommended to activate the hardware flow control and/or to change the clock edge.

About the divider in Card identification Mode, the specification indicates we should be at 400 kHz, so in the driver we should take in account the world case. So of course it means it will be slower during the card identification mode if the clock is not configured at 48 MHz.

Best Regards,

Imen

[Tesla DeLorean]

As I recall MICRO SD cards were supposed to be good to at least 50 MHz

People are likely to need to tailor the drivers to their own needs and commercial standards. Perhaps having fall-back and retry methods rather than shoot for the least-common-denominator.

Should perhaps pull the parameters from the cards, and identify make/model/capacity so as to black list bad cards or alert use users, and at the very least provide a means for technical support staff to gather information product engineers can actually act upon.

[Steve Melnikoff]

These all sound like sensible suggestions.

In our case, we use a specific make and model of SD card for this project, so we can tailor the code accordingly. We all seem to agree here that this feature should work at full speed, so it's not clear why we had problems.

Regarding least-common-denominator, I guess that's up to ST. However, this is a single register read that happens once, at startup, so the penalty for running at 400 kHz here is minimal.