STM32H747I-DISCO Question(s): Why D-Cache needs to be enabled when using f_open / SDMMC

[JW]

Background:

I am using the STM32H747I-DISCO board and the BSP SDMMC example from the ST Repository as my starting point.  I can provide my code if necessary but wanted to keep post as short as possible.  I have looked at AN4838, AN4839 and AN5200 ST Micro Documents.  They are detailed but not getting me to my answer fast enough.

My Goal:
I am trying to understand the detailed reason(s) why I need to enable the D-Cache when using FatFS calls with the SDMMC peripheral on the STM32H747I-DISCO board to avoid a timeout and also why I-Cache does not necessarily need to be enabled.  

My Understanding to this point:

The CLIFF NOTES of what I think I understand (between the ST documentation, AI hallucinations and true answers):

Enabling the D-Cache reduces AXI bus contention since the IDMA in the SDMMC peripheral needs AXI bus to move data from the FIFO to SRAM on a very tight timeline, mandated by the SDMMC peripheral.  When you enable the D-Cache and call f_open, (supposedly) the CPU Core (Cortex M7) is making numerous requests over the AXI bus like parsing path, reading directory structure and FAT tables, checking flags etc.  The initial call to f_open populates D-Cache.  When the CPU core continues to request the data it needs, it retrieves the data from the D-Cache instead of requesting get data from SRAM.  Under this condition, the CPU core does not need the AXI bus, allowing the IDMA to move data from the SDMMC FIFO to SRAM (over AXI) and meet its timeline.

My question(s):

1) Is my understanding accurate?  If not can you correct me/point me to the documents that clear this up?

2) Why does enabling I-Cache not seem to matter?

3) Is there a section of the Application Notes of perhaps a ST Micro User Manual doc that explains this?

Any guidance / RTFM pointers are appreciated.

JW

[TDK · Accepted solution]

DCACHE does not need enabled in general.

If you drilled down to what is actually happening on the line, you would probably find a race condition is lost--the SDMMC peripheral doesn't get the data in the time that it needs it. The endless obfuscation in the FATFS library and the HAL implementation of it makes this obnoxiously difficult to do. This doesn't use FATFS, so tracing down what exactly fails, where and (maybe) why should be straightforward.

I doubt the issue is bus contention but rather just the raw speed of execution. The AXI bus is fast--much faster than whatever data rate you're reading out over SDMMC. Enabling DCACHE makes code go so much faster so it wins the race condition. Compiling with Release settings may do the same. ICACHE does not have as much of an effect in terms of execution speed.

Lowering the SDMMC bus speed should also make things work with DCACHE disabled if the problem is either bus contention or code execution speed.

Just a guess based on my experience with SDMMC on STM32 chips.

[JW]

Thank you for responding.  Looking into it...

[JW]

This is the correct answer.  Thank you!