cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 - SDMMC/SDIO not working, wrong Signal-Levels

TTimm.1
Associate II

Hi,

I have a similar issue like this:

https://community.st.com/s/question/0D50X00009XkWtOSAV/stm32h7-sdmmc-not-working

Host: "Nucleo-STM32H743"

Target-Interface: SDIO V2.0 Clk = 12 MHz (Silabs WFM200S)

-error pattern:

At "read_cmd53" the 3V3-Signallevel breaks down in SDIO-Command-Line.

the "read_cmd53"-Command fails...

see this:

0693W00000Dn7BQQAZ.png 

This Application runs fine on a Nucleo-STM32F429.

(with the exactly same Hardware !!!)

see this:

0693W00000Dn7D7QAJ.png 

Details:

Voltage-Scaling is "PWR_REGULATOR_VOLTAGE_SCALE1" (high performance)

all app runs in "DTCMRAM", RAMD1-3 not used at all

use PLL2 with "sdmmc_ker_ck" = 120MHz

Clk-Divider_400kHz = 150

Clk-Divider_12MHz = 5

AHB3-Clk = 84MHz

under the suggested link above "Torsten Jaekel" wrote:

1. make sure the ClockDivider is not too small (with flying wires, I use hsd1.Init.ClockDiv = 96;

   (try a bit, I saw that CMDs on SDIO can fail if too fast)

2. check what is the PCLK soure (where to get the SDMMC clock from):

   what is the PCLK source and frequency? I use PLL1 (PLL2 seems to fail for SDMMC1)

3. Make sure, all the memory and buffers used by SDMM1 are really

just on AXI SRAM

(D1).

Meanwhile, I spend a lot of time to get the Interface running...

Are there further recommendation to fix this issues?

I will move back to PLL1 and also move from DTCMRAM to RAM_D1.

Hope it helps...

Kind Regards

Thomas

4 REPLIES 4
TDK
Guru

Note that the F4 and H7 libraries for SDMMC are different, at least they were the last time I checked, with (I think) the H7 implementing more features.

Slow down the clock by an order of magnitude. If that works, you have something to go from.

If you feel a post has answered your question, please click "Accept as Solution".
TDK
Guru

On a closer look, the waveforms aren't the same. The first one has very poorly defined edges. If slowing the clock fixed it, that's likely the problem. Definitely something is different in the hardware (or gpio hardware settings).

0693W00000DnAZVQA3.png

If you feel a post has answered your question, please click "Accept as Solution".
TTimm.1
Associate II

Hi TDK,

some (bad) news...

I moved back to PLL1and changed the RAM in Linkerscript (from DTCMRAM to RAM_D1)

(as suggested by T. Jaekel)

In my Opinion, the Result are more worst like before.

Let's start:

0693W00000DnCBkQAN.pngHere you can see, the Read-Data from Target will never send. (with 10k Pullup in CMD-Line)

/////////////////////////////////////////////

0693W00000DnCCiQAN.png 

This is when I used the Onboard-Pullup (82k) on the Target-Board in parallel with the STM32-Pull-ups. (approx. 40k)

The CMD-Line (light blue) breaks down immediately, the D0-Line (dark blue) and D1-Line (lilac) are not stable...

What's wrong here?

Again: Plug the Nucleo-F429 under the Target-HW -> perfect,

plug the Nucleo-H743 under the Target-HW -> chaotic signals.

The Setting for the GPIOS are GPIO_MODE_AF_PP / GPIO_PULLUP / GPIO_SPEED_FREQ_VERY_HIGH (same like F429)

To me, it looks like the Port-Supply (Port C/D) are not nailed to Vdd or something in the Supply is weak.

I don't have found in the RefMan from witch Domain the SDMMC-Unit is powerd (D1?).

in SystemClock_Config() the Supply is set to HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);

Maybe, a Power-Safe-Function causes that issue?

Next I will half the SDIO-Clock.

But with the exactly same HW the App run with Nucleo-F429ZI.

TTimm.1
Associate II

I attach the *.ioc-File from CubeMx-6.3.0.

Kind Regards

Thomas