cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H725 SD Card errors after debug suspend

JOlso.1
Associate II

While debugging, program execution after (or during) sd card initialization causes the SDMMC module to return errors while executing commands for subsequent calls.

STM32CubeIDE v1.10.0, Build 12671_20220627_1643

Debugging with STLINK-V3MINIE

Using the auto generated code

-SDMMC2, 4 bits wide bus, rising edge clock, hardware flow control, no external transceiver, clock divide factor 4 (25 MHz)

-FatFs file system also through the auto-generated code

I can init, mount, read/write successfully.

However, any breakpoint, anywhere following the initialization of the SDMMC module causes subsequent commands to fail with error code 4 (CMD_RSP_TIMEOUT). Including during the initial connection to the SD card.

Potentially useful information

The SD clock continues at the same frequency during the breakpoint (though i don't know if there's a momentary interruption).

The debugging interface through cubeIDE seems to read all the SFR on a break, are there any side effects to reading out the registers in this way?

2 REPLIES 2

A breakpoint halts the CPU - so it won't be able to service anything required to maintain the SDMMC.

So that's always going to be an issue with debugging a real-time system.

Some peripherals have configuration options to control what happens during a debug halt; whether they carry on, or stop, etc - maybe investigate that?

A CPU halt shouldn't be an issue for an externally connected SD Card unless it happens during a command/response. There is no bus maintenance to be done, as the MCU is the host and initiates all communications. I have also just verified, there are no SD/SDMMC interrupts being called between transfers. I've read online that a halt of the SD clock is supposed to be allowed by the standard but can cause issues with certain cards. Which is why i mentioned that clock is not suspended.

On STM32H7 the register for peripheral debug halting is DBGMCU. I see no configuration bits related to the SDMMC peripheral, or the D2 Domain where it's located.

I'm hoping someone else can tell me whether this is an issue for them as well, and if i'm really lucky a fix.