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

[TTimm.1]

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:

 

This Application runs fine on a Nucleo-STM32F429.

(with the exactly same Hardware !!!)

see this:

 

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

[TDK]

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.

[TDK]

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).

[TTimm.1]

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:

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

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

 

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]

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

Kind Regards

Thomas