Clive One

STM32H743XI SDMMC Clocking

Discussion created by Clive One on Feb 16, 2018
Latest reply on Feb 16, 2018 by Clive One

The documentation for the H7 lacks clarity, clocking details are confusing, and software uses an interpretation that doesn't seem to reflect reality.

 

Test board : STM32H743I-EVAL

Test software basis : STM32Cube_FW_H7_V1.2.0\Projects\STM32H743I_EVAL\Applications\FatFs\FatFs_uSD_Standalone

 

I've modified the base software to provide telemetry and diagnostic information via VCP.

 

sdmmc_ker_ck is assumed to be 200 MHz, code comments also infer

 

SDMMC_CK = sdmmc_ker_ck / (2 * CLKCR.CLKDIV)

 

For the 400 KHz bring up in stm32h7xx_hal_sd.c uses an SDMMC_INIT_CLK_DIV of 250

 

200,000,000 / (2 * 250) = 400,000

 

For an Ultra SD (SDXC) card, not 1.8V rated apparently, results in the CLKCR.CLKDIV = 4, regardless of the setting in uSdHandle.Init.ClockDiv 

 

200,000,000 / (2 * 4) = 25,000,000 (25 MHz)

 

CLKCR.WIDBUS =1 (4-bit)

 

If I actually benchmark raw reads (read into memory, don't process it)

 

32768000 Bytes, 2285727581 Cycles
 5.73 MBps Read (FatFs)
32768000 Bytes, 2285693655 Cycles
 5.73 MBps Read (FatFs)
11440 ms run time [both passes so ~65MB total]
 5.73 MBps (Sanity Check)

 

This strongly suggests a bus that's actually clocking at 12.5 MHz, figure 6.25 MBps ceiling for the 4-bit transfer in saturation.

 

With CLKCR.CLKDIV = 1

200,000,000 / (2 * 1) = 100,000,000 (100 MHz)

 

32768000 Bytes, 692466639 Cycles
23.66 MBps Read (FatFs)
32768000 Bytes, 692435843 Cycles
23.66 MBps Read (FatFs)
2781 ms run time
23.57 MBps (Sanity Check)

 

Don't have a good way to probe the actual clock, but this should be possible for a 50 MHz 4-bit transfer. I've run a CRC on the files with assorted block sizing, and everything checks out as valid. Might check the NUCLEO-H743ZI with a scope tomorrow.

 

The software is a bit of a dogs-breakfast, it uses arbitrary constants when it would be much better to compute the clock settings based on the clock sources being used and a desired target rate (like the USART baud rate). The SDMMC peripheral on several of the STM32 parts seem to have an assorted combination of clock sources, different PLL, different taps, the L4R9 seems to have 3 or more potential sources, and comments in the code are frequently muddled and code seems to be ported across half a dozen L4 boards.

 

The point of HAL presumably is to provide an orthogonal solution across chips and families, but there is so much stuff provided as #defines and spread all over the place. This is going to get increasingly difficult to manage as parts within the same family now have an assortment of different IP. The HAL really should manage/hide this chip level minutia as much as possible.

Outcomes