Request for explanations regarding the ICACHE of H5

[Nikita91]

Using an STM32H5 I recently came across a problem: triggering a hard fault when accessing data in FLASH (read FLASHSIZE_BASE).
It turns out in this thread that the ICACHE being validated, it is necessary to configure the MPU to make “uncacheable” the part of the flash to which we want to access. This seems to contradict the fact that ICACHE is made precisely to serve as a flash cache...

This leads to a host of questions…

How does the ICACHE (Instruction CACHE) intervene in access to data?
It is not clear to me why read-only data should not be cacheable.
If my application places data in FLASH and I need to access it, will it also be necessary to use the MPU?
Is there a list of areas of the address space that need to be made “non-cacheable” to be able to access them securely?

Does this apply to all families using the Cortex-M33: L5, U5, H5?
What are the differences regarding ICACHE and data access between these families?

It seems that Icaching is not just about instructions, but also about data.
This cache is also active on internal SRAM areas.
How does this work when using DMA? Should we do cache management as with MPUs having a data cache (the H7 for example)?
While the M33 does not have a data cache. And that ICACHE has only one maintenance instruction: total cache invalidation.
Or use the MPU to define a non-cacheable region containing all RAM?

I would like ST to write an extensive article in the knowledge base to answer these questions (and those that others will think of…).

Thanks.

[Pavel A.]

See here: https://community.st.com/t5/stm32cubeide-mcus/dcache-on-stm32u599/td-p/619152

[Sarra.S]

Hello @Nikita91, 

Please take a look at this article, it answers some of your inquiries: 

How to avoid a hard fault when ICACHE is enabled on the STM32H5 series

 >>Does this apply to all families using the Cortex-M33: L5, U5, H5?

No, this applies only to the STM32H5 series. 

Hope that helps! 

[Nikita91]

Thank you for these explanations, especially the difference H5 vs L5/U5 and H503 vs H562/63/73

But this does not address the interaction between SRAM and ICACHE when a DMA is used.

Should the entire cache be invalidated after a DMA reception that writes to SRAM, and before accessing the data?

Should I do an ICACHE flush before starting a DMA in transmission (which reads the SRAM) after writing the data and before starting the DMA?
But ICACHE has only one maintenance instruction: total cache invalidation.
Cache line management is necessary with standard caches. But ICACHE seems quite special...

Perhaps the correct answer would be to know what SRAM data passes through C-Bus and ICACHE?

[not_cheater]

I have the same issue as Nikita91 regarding the STM32H5 series.
Is there a need for maintenance when the ICACHE and DMA are operating together?
According to the article you provided, the ICACHE caches data and operates in a mode similar to write-through, read allocate (approximately). So, I guess there might be a need to maintain the DMA receive buffer. Could you please clarify this?

[not_cheater]

Do you have a definitive answer regarding the issue with DMA and ICACHE on the STM32H5 series? Based on my simple test (receiving data via UART using DMA), it seems that I can read the correct data even without maintaining the ICACHE. However, I'm concerned that this might pose a potential risk.