STM32H757 SDMMC + FATFS consistently returns FR_NOT_READY
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:
- 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.