cancel
Showing results for 
Search instead for 
Did you mean: 

The issue that the SDIO operation SD card of STM32F407 can only read but not write

ChenJingtai
Associate II

Hello, when I was using the SDIO of F407, I encountered a problem where the SD card could only read but not write. When I enabled "HardwareFlowControl" and set "ClockDiv" to 2, the function was normal. Why is that? When I operate the SDMMC of the H750, it's the same. It must be set to the above Settings.I checked the waveform of the SD card. In terms of waveform quality, it's okay.The waveform of the clock is shown in the following figureiShot_2026-05-19_04.02.36.png

1 ACCEPTED SOLUTION

Accepted Solutions
jimmyande0
Associate II

This behavior usually points to a timing/clock configuration issue rather than a pure signal integrity problem.

Enabling Hardware Flow Control and reducing ClockDiv improves the SDMMC/SPI timing margin, which can make write operations more reliable especially if the card is sensitive to command/data timing skew.

Even if the waveform looks clean, SDIO/SDMMC write operations are much more timing-critical than reads, so small setup/hold violations or internal FIFO timing issues can cause exactly this kind of “read OK, write fails” behavior.

It’s also interesting that both F407 and H750 show the same dependency that suggests it’s more about the SD card + interface timing combo rather than a single MCU bug.

Worth double-checking:

  • SD clock frequency vs spec limit of the card

  • CMD/DAT line pull-ups

  • SD bus mode (1-bit vs 4-bit)

  • FIFO/flow control settings consistency

Good catch on the fact that adjusting ClockDiv fixes it — that’s a strong hint it’s timing margin related rather than hardware damage or wiring issues.

View solution in original post

2 REPLIES 2
jimmyande0
Associate II

This behavior usually points to a timing/clock configuration issue rather than a pure signal integrity problem.

Enabling Hardware Flow Control and reducing ClockDiv improves the SDMMC/SPI timing margin, which can make write operations more reliable especially if the card is sensitive to command/data timing skew.

Even if the waveform looks clean, SDIO/SDMMC write operations are much more timing-critical than reads, so small setup/hold violations or internal FIFO timing issues can cause exactly this kind of “read OK, write fails” behavior.

It’s also interesting that both F407 and H750 show the same dependency that suggests it’s more about the SD card + interface timing combo rather than a single MCU bug.

Worth double-checking:

  • SD clock frequency vs spec limit of the card

  • CMD/DAT line pull-ups

  • SD bus mode (1-bit vs 4-bit)

  • FIFO/flow control settings consistency

Good catch on the fact that adjusting ClockDiv fixes it — that’s a strong hint it’s timing margin related rather than hardware damage or wiring issues.

Hello, you're quite right! You mean to ask me to pay attention to the frequency limit of the SD card itself. I checked my card, which belongs to class10 and has High Speed and Default Speed. Theoretically speaking, their clock buses can reach 50MHz and 25MHz. However, after my measurement, I found that after the STM32F407 was divided into two frequencies, the clock line speed of the SD card could reach 12MHz, and after the STM32H750 was divided into two frequencies, the clock line speed of the SD card could reach 50MHz. It is obvious that the STMF407 has not reached the upper limit of the SD card, so I am very puzzled about where the problem lies.