Skip to main content
JOlso.1
JOlso.1
Associate
July 15, 2022
Question

STM32H725 SD Card errors after debug suspend

  • July 15, 2022
  • 1 reply
  • 1011 views

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?

This topic has been closed for replies.

1 reply

Andrew Neil
Andrew Neil
Super User
July 15, 2022

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 complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
JOlso.1
JOlso.1Author
Associate
July 15, 2022

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.

Terms & ConditionsAccessibility statement