Default MPU Configuration for STM32H573

[DPade.1]

Does ST have a good default MPU configuration for the STM32H573?  When I start a CubeMX project for the H7 series, it asks if I want to use a default configuration.  But for the H5 it does not.  While I can find forum posts regarding the need to disable iCache or use the MPU to work around hard faults, I have found no examples or suggestions for a default MPU setup for the H5.

Also, the settings in CubeMx are different than on the H7 series.  The options are poorly documented and I'm not sure what they mean. Even the ARM documentation fails to explain what the options mean or do.  For example "MPU Device" options are all variations of MPU DEVICE nGnRnE, but the ARM documentation implies there should be a "Normal" option for here.  Also there is no "ALL ACCESS NOT PERMITTED" option for MPU Access Permissions.

Anyway, I feel like ST should provide an example or summary for proper MPU setup for all on-chip memory/peripherals.  Where would I find it?

I found a list of MPU permissions listed in the Programming Manual (PM0264 Section 2.3.5).  If I enable the MPU, does it fully override the defaults listed in the Programming Manual (do I need to redefine each region) or do I only need to define regions that need modifications?

For example, I need to disable iCache access to the OTP and RO regions (so I can access the UID).  Do I only need to define one region in the MPU to block iCache access to that region as in https://community.st.com/t5/stm32-mcus/how-to-avoid-a-hard-fault-when-icache-is-enabled-on-the-stm32h5/ta-p/630085 or will that also disable all other default MPU region settings?

[tjaekel]

Actually, there is not a default MPU configuration possible. All depends how you want to handle memories, which mode, e.g. "Write Through" vs. "Write Allocated". Nobodies knows which memory region should be uncached and which cached etc.

The MPU config goes along with your linker script and with your code. For instance: when using ETH with DMAs - there is a region on memory needed which is uncached. This is used to store the DMA descriptors there. A DMA cannot read "instructions" (descriptors) from MCU cache. So, you had to know your memory regions and setup the MPU accordingly.

BTW: I think, the MPU does not have any reasonable default settings. There is not a region enabled, neither the addresses for the regions are known, therefore not set.

And ICache is not related to MPU. ICache is separate, can be enabled and disabled separately. Actually, the same for DCache: if you enable DCache without MPU configure, not enabled - all becomes cached, with "Write Allocate". You might need regions not cached or with "Write Through": now you have to configure the MPU.

And MPU as "workaround for hard faults"?
I think, this is not the intention and neither really possible. Instead, you get a chance with MPU to see now additional traps, e.g. Bus Errors. This is the intention: inform the "user" when he violates the setting for memories, e.g. executing code on SRAM, writing into Read-Only regions etc.

The MPU is often "just" needed if you have to make sure not to have caches when DMAs are used, to have a different cache policy if DMA (or dual-core) is used or you want to make your FW "rock solid" in terms of "potential memory violations" (SW bugs). Now the MPU trap is fired and gives you a clue where it happened and the reason.
So, the MPU might avoid to get HardFault Handler called - instead you get now MPU triggered and firing other event/INT (I think Bus Error).

[STOne-32 · Accepted solution]

Dear @DPade.1 ,

Thank you for the interesting question , indeed STM32H7 contains Cortex-M7 core which has a native L1 Cache and this core is designed before Cortex-M33 which is an extension for M4 with TZ - so not the same architecture and not same usage of MPU attributes versus security. M7 is focused on High performance throughput and so delivering much power thru the MCU architecture while dealing with L1 Cache . A very important MPU setting and warning with some memories are the M7 speculation feature as described here  , Section 3.4

 

https://www.st.com/resource/en/application_note/dm00272912-managing-memory-protection-unit-in-stm32-mcus-stmicroelectronics.pdf

Then, as said by @tjaekel  it will depends on your hardware configuration and special memories mapped and shared among the different Masters . 

H5 case for MPU setting for RO data is very particular ( we can assume it as a « voluntary errata » from initial design ) due to the fact that we have a special ECC flash optimization and was our design choice when the ICache is activated , you refer to our Knowledge Article here :https://community.st.com/t5/stm32-mcus/how-to-avoid-a-hard-fault-when-icache-is-enabled-on-the-stm32h5/ta-p/630085

Hope it helps you a to understand the choices.

STOne-32

[DPade.1]

@tjaekel,

I understand the usage variability depending on particular applications (especially the need to configure DMA is very application-dependent), but if there are requirements for MPU configuration to use all of the onboard memory and peripherals, those should be well documented.  What I'm suggesting is a starting point or template to get most users up and running, and from there make a few adjustments or add some new regions to manage DMA or other requirements.  In fact restricting DMA is just 1 of many possibilities with the MPU configuration.  What about Shareability, Transient, Allocate, and MPU Device settings?  These options exist but when should/shouldn't they be used with respect to the onboard memory map?  How do we know the proper settings for onboard memories and peripherals?

In fact, instruction cache IS related to the MPU because, as in the fix to avoid the hard fault when reading RO and OTP memory, we use the MPU to disable instruction caching of the region.  Hence, with MPU disabled, iCache falls back to default memory access configurations (ST has noted these in the Programmer's Manual I referenced in the original post).  But we can enable and use the MPU to adjust the configuration for the RO OTP region to avoid the problem.

Based on what I've learned so far, it seems that the Programmer's Manual documents the "default" access configuration I am looking for, which takes effect so long as the MPU does not override it.  It's just there is a sort of errata (as @tjaekel noted) that causes the defaults to throw a hard fault for the RO OTP region.  Looking at it this way makes more sense to me. 

[DPade.1]

@STOne-32,

Thank you for the response.  Looking at the issue as more of an errata helps me make sense of this issue.  I think that the Programmer's Manual provides the so-called default configuration I was looking for, but for this one region of memory we have an issue with the iCache.  Essentially, if the MPU is not used or if an MPU region does not override the default accessibility settings defined by ST, the caches use the predefined default access.  If the MPU is enabled and defines a region, the cache's are subject to the MPUs configuration.

Also, I tested that I only have to define the 1 region for the RO OTP cache restriction as suggested in the referenced article.  Is there a way to confirm that icache (or dcache for that matter) are properly working in other regions not covered by the MPU?  Or is it just given that regions not defined in MPU will fall back to the predefined access configuration noted in the Programmer's Manual?

[DPade.1]

Sorry, I incorrectly tagged @tjaekel regarding the errata.  I meant to tag @STOne-32 for that note.