I’m working on an STM32H7R7 project using SDMMC1 + FreeRTOS (CMSIS-RTOS v2) + FatFs, all generated with STM32CubeMX.
I’m facing an issue where the system blocks inside f_open() and never returns, so the return value cannot be checked.
A key aspect of the problem is that the behavior depends on how the device is started:
After flashing the firmware with a debugger connected and running immediately, the system behaves differently.
After a cold power-up (power removed and re-applied, no debugger connected), the same binary consistently freezes when reaching f_open().
In both cases:
This suggests a timing-, initialization-, or peripheral-state-related issue that manifests only on a true power-on reset and not after a debugger-initiated reset.
Additional observations:
f_mount(&SDFatFs, "0:", 1) initially caused a block, but changing to f_mount(..., opt = 0) resolved the mount stage.
The freeze now occurs only when f_open() is called.
GPIO instrumentation shows that the SDMMC1 interrupt fires during f_open(), but the system never exits the function.
Because the failure happens only after a cold start and not after flashing/debug reset, it appears that some SDMMC, DMA, cache, or RTOS interaction behaves differently between power-on reset and debug reset, even though the application code is the same.
Does anybody have any solution?
Note: I used the newest cubemx (6.16.1)
