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.

[Steve Melnikoff]

Hi Imen. Thank you for looking into this.

The SD card we use is a Transcend TS16GUSDC10I.

We tried with a couple of other random SD cards as well, with varying results.

Is it likely to make a different that we are running the processor (and hence SDMMC) at 8 MHz (i.e. no PLL)?

[Imen.D]

Yes, there is a huge difference when running at 8 MHz.

Everywhere in the RM it is indicated that a specific 48 MHz clock is used for the SDMMC. By default the HSI48 is used (for STM32L4+ series and STM32L496xx / L4A6xx lines) or no clock (for other L4 products).

We have performed a check with a processor configuration at 8 MHz through MSI configuration and use same MSI configuration for the clock used by SDMMC (so 8 MHz instead 48 MHz) and we don't encounter any problem (SCR reading is correct and non-regression tests also).

We didn't modify any divider so the configuration is not full speed.

So what is the clock configuration used for the SDMMC (field CLK48SEL of register RCC_CCIPR and field SDMMCSEL of register RCC_CCIPR2 in case of L4+ serie) ?

[Steve Melnikoff]

> Everywhere in the RM it is indicated that a specific 48 MHz clock is used for the SDMMC

That was not my inference at all. The reference manual does mention using a 48 MHz clock; but I have not found anywhere where it says that a 48 MHz clock must be used. Indeed, the datasheet talks about data transfer "up to 48 MHz", and the the electrical characteristics section for SDMMC specifies the data clock as being in the range of zero to 50 MHz.

I can understand that this might be required for USB, where you're talking to another device with its own clock. But for an SD card, our assumption was that this was a maximum speed, so going more slowly would be fine.

In other words, if running SDMMC at anything below 48 MHz is out of spec, this needs to be explicitly stated in the documentation.

If it's not out of spec, then it should work - and our experience has been that the hardware works fine, once the software has been tweaked.

> So what is the clock configuration used for the SDMMC

CLK48SEL = 0x3, i.e. MSI, where MSI is set to 8 MHz.

SDMMCSEL is not available on this processor.

[RScha.2]

Can confirm, we have the exact same issue with newer SD card, and running the findSCR function @ 400KHz works. Tested findscr with a variety of SD cards at different clock speeds, with same results, some respond some of the time etc.

Regards

[Steve Melnikoff]

Glad it's not just us then! :)

[RScha.2]

Thanks for the solution BTW ;) , kept me busy for quite a while, since it only failed sometimes in field, but with newer cards it seemed to be failing more often.

[Imen.D]

We don't reproduce the issue with several cards from several manufacturers, capacity and version.

We need more details about the faulty SD cards (Manufacturer, SD version, Capacity, ...) ?

[RScha.2]

Hi Imen,

Thanks for the reply. The error was quite scarce, not a frequent error, most of our devices can be reset manually and work can continue.

In order to test properly, our code was changed to repeatedly initialize the SD card thousands of times until an error occcured. On some occasions only after 800 initializations did the findscr function fail. Some cards failed between 10-300 iterations.

With the 400KHz setting, each card passed reinitilizations many times.

Not sure if other peripherals or routing has an affect, as we have 2 different hardware designs, with thousands in field for both, and it is only one type that is failing.

Both hardware designs use 'STM32F437IG-T6

Regards