STM32H533 DCACHE seems to make no difference?

[devinw]

So I've got a program with a fast tight loop doing some minimal things, and the rest is housekeeping/UI stuff in the main loop. When I enabled ICACHE, the speed of the tight loop increased DRAMATICALLY and overall the process is faster at basically everything. A colleague of mine said that he uses the DCACHE also and that for his application on an H7, the DCACHE made a huge performance improvement. But, as far as I can measure (which is toggling GPIO pins at critical sections of code and measuring the time with o-scope), the DCACHE made no difference on or off.

 

So for now I 'm just leaving it off because I know I need to be careful with DCACHE and my SD Card etc. and it's easier to just leave it off, but I'm wondering what areas/use cases is the DCACHE actually supposed to improve with this chip?

[Tesla DeLorean]

Per the Reference Manual the connectivity for the DCACHE (4KB) is the OCTOSPI and FMC, so code/data on external memories likely to be where you'd see it.

The SRAMs all look to be relatively closely coupled

https://www.st.com/resource/en/reference_manual/rm0481-stm32h52333xx-stm32h56263xx-and-stm32h573xx-armbased-32bit-mcus-stmicroelectronics.pdf#page=107

[devinw]

Thanks, that's a good point. I'm not using the OCTOSPI or the FMC for anything, so that would correlate to what I'm seeing.

[Tesla DeLorean]

Not sure the caching would impact the SDMMC in this context.

The H7 is a particularly odd beast, designed as a dual core, with dual ported memories. The F7 on the other hand can use the DTCM for SDMMC DMA, and that's not cached.

You want the DMA 4-byte aligned. On the H7 the cache lines are 32-byte aligned, and SDMMC there is workable with care, as the clear/invalidate by address need to span the buffer, it they are miss-aligned you can get collateral damage to structures directly abutting the SDMMC DMA buffer.