STM32H7 with FatFS on eMMC sometimes failing

[TVare.1]

Hello everyone,

I have a project using the STM32H7, using FreeRTOS and with a FatFS (ChaN) runnin on a 4GB eMMC (Kingston), using peripheral SDMMC1.

Normally everything works fine. SDMMC1 and FatFS (FAT32) are initialized at main, before OS, and is used later on for many things such as creating and writing/reading files, etc.

However, we found some devices that were working fine and suddenly (after a couple of thousands of writings in the eMMC, I'd assume not too intense) we start having a constant and reproducible error. What happens is that the FatFS initializes OK but as soon as we want to write something (still at main, before OS), it fails. Basically when trying to open a file (that already exists) it fails with FR_DISK_ERR and we cannot use the FatFS anymore. Trying to debug a bit, I saw that on the lowest level HAL_MMC_ReadBlocks (from stm32h7xx_hal_mmc.c) is failing with HAL_TIMEOUT.

However, if I send a "reset" command to our device (it basically just executes a __NVIC_SystemReset of CMSIS on the STM32), on the following boot everything works fine. Both the issue and the "fix" are constant and once they happen once they start happening every time. FYI, the eMMC is also powered off/on when booting (we control this with dedicated circuits controlled by main uC).

I'm aware there are many layers where the failure could be:
1) HW? but then why most devices work fine and those failing are consistent once they start failing?
2) ST HAL: could be some casuistic triggering any bugs?
3) FatFS: something related to the FAT gets corrupted inside the eMMC? We do mount and access the eMMC via USB and so I tried formatting it (from PC with Windows) and didn't make a difference...
4) A combination of electrical/eMMC/firmware conditions ¿?

I suspect that the conditions are somehow also related to using Standby low-power mode, since I cannot reproduce it if I just use Stop mode. Initially I don't see why this could be affecting, since as far as I understand when waking up from Standby mode the STM32 reboots and therefore everything would be initialized the same way.

Since it has this characteristic of stop happening after a SW reset, but then happening again on following boot when powered off/on, I figured maybe someone would identify any other potential issue... Any ideas of what could be or what should I check?

Thanks in advance!

[Tesla DeLorean]

Long linear reads/writes are easier to predict and pre-buffer / pre-fetch.

eMMC also has a method to front-run the erase if you tell it how large the transfer is.

Pre-erasing helps as the erase size is large and the pool of erased blocks can be better managed, and not churned. The low RAM availability on MCU's can also limit the layers of buffering, caching and deferred / lazy writing.

[MMARI.1]

hi @TVare.1 ,

you have solved your issue ? since i am planning to use eMMC in SDMMC mode .

hi @Tesla DeLorean 

eMMC RST Pin remains as open (or) RST Pin should be Pulled up with 4.7K.

[Tesla DeLorean]

Depends on the nature of the signal you're presenting as to whether you'd need another at the eMMC

But if driving by a GPIO-OD, a pull-up in the 4K7 to 47K range would be fine. You should review the datasheet(s) for the part(s) of interest

A reasonably complete implementation is presented here:

https://www.st.com/resource/en/schematic_pack/mb1381-h745xi-b03-schematic.pdf#page=10

Speed/performance is going to depend on the file system using large aligned blocks, and informing the device of the size of transfer (where supported) for writes so it can pre-erase and not churn through resources.