FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

STM32H757 SDMMC + FATFS consistently returns FR_NOT_READY

Sasa1234
Associate III

‎2026-05-07 7:25 AM - last edited on ‎2026-05-07 7:30 AM by

Hello,

I’m working on an STM32H757 (Cortex-M7 core, dual-core system) using SDMMC1 + FATFS (CubeMX-generated stack) and I consistently hit a blocking issue:

  1.  Core issue

f_mount() always returns:

FR_NOT_READY

or the execution breaks inside Error_Handler() depending on build/debug timing.

 Hardware / system context

  • MCU: STM32H757 (Cortex-M7, DCache enabled)

  • SD interface: SDMMC1, 4-bit mode

  • DMA: enabled (CubeMX SDMMC DMA configuration)

  • External subsystem: Riverdi TFT display 12.1 inches (LTDC active)

  • FATFS: CubeMX middleware (generic SD diskio template)

  • No RTOS

 Software architecture

  • STM32CubeIDE latest

  • HAL SDMMC driver (CubeMX generated)

  • FATFS with sd_diskio.c DMA template

  • BSP layer present (mixed HAL/BSP abstraction)

  • Cache enabled (I/D Cache ON, MPU default CubeMX config)

Observed behavior

During initialization:

  • BSP_SD_Init() returns OK

  • SD card is physically detected

  • HAL_SD_GetCardState() does NOT consistently reach SD_TRANSFER_OK

  • SD_CheckStatusWithTimeout() frequently times out

  • FATFS layer reports:

FR_NOT_READY

Mount never succeeds.

Key observations (important)

  • SDMMC peripheral initializes without error

  • DMA transfer callbacks are triggered inconsistently

  • No explicit DCache maintenance is performed in user code

  • MPU remains CubeMX default (no SD/DMA region tuning)

  • sd_diskio.c is the CubeMX DMA template version (unaltered logic)

 Suspected root causes

At this point I strongly suspect one (or more) of the following:

1. Cache coherency issue (most likely)

No explicit:

  • SCB_CleanDCache_by_Addr

  • SCB_InvalidateDCache_by_Addr

around SDMMC DMA buffers.

Given Cortex-M7 behavior, this alone can fully explain:

  • stuck SD state machine

  • invalid transfer completion flags

  • FATFS seeing STA_NOINIT → FR_NOT_READY

2. MPU configuration not DMA-safe

Default CubeMX MPU configuration appears unchanged.

Risk:

  • SDMMC DMA buffer located in cacheable region

  • or MPU attributes conflicting with DMA access

3. SDMMC HAL/BSP mismatch

CubeMX-generated stack mixes:

  • HAL_SD

  • BSP_SD_*

  • FatFS diskio DMA template

The abstraction layering is inconsistent and may be causing:

  • incorrect card state polling

  • race conditions in BSP_SD_GetCardState()

4. SDMMC clock / init sequencing sensitivity

Even though init returns OK, the card never reliably reaches transfer state under FATFS load.

 Question to ST / senior devs

Is there a known stable reference configuration for STM32H757 SDMMC + FATFS + DMA that actually works under Cortex-M7 cache enabled system?

Specifically:

  • Is DCache maintenance mandatory in sd_diskio.c for H7 family even with BSP DMA template?

  • Should MPU explicitly mark SD DMA buffers as non-cacheable?

  • Is the CubeMX SDMMC DMA template actually valid for H757 or known broken in real-world use cases?

  • Any recommended HAL/BSP layering for stable FATFS on H7?

At this point the behavior looks less like an application bug and more like a system-level coherency issue in the generated stack.

Any concrete working reference or confirmed fix would be appreciated.

Thanks.

0 Kudos
0 REPLIES 0
Top