STM32H7 MPU shareable memory attribute and strongly ordered memory type

Question

I am confused by some of the attributes of the STM32H7 MPU.

I've read several documents: STM32H7 reference and programming manual, STMicro application note on MPM, etc...

I've understood that shareable is exactly equivalent to non-cacheable (at least on a single core STM32H7). Is it correct?

I need to define a MPU region for a QSPI Flash memory. A document from MicroChip (reference TB3179) indicates that the QSPI memory should be configured as Strongly Ordered. I don't really understand why?

Answer 1

Question: I've understood that shareable is exactly equivalent to non-cacheable (at least on a single core STM32H7). Is it correct?

Here's an ST guide to MPU configuration:

https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/STM32_MPU_tips.html

If some area is Cacheable and Shareable , only instruction cache is used in STM32F7/H7

As STM32 [F7 and H7] microcontrollers don't contain any hardware feature for keeping data coherent, setting a region as Shareable means that data cache is not used in the region. If the region is not shareable, data cache can be used, but data coherency between bus masters need to be ensured by software.

Shareable on STM32H7 seems to be implicitly synonymous with non-cached access when INSTRUCTION_ACCESS_DISABLED (Execute Never, code execution disabled).

Furthermore,

https://community.arm.com/developer/ip-products/processors/f/cortex-a-forum/5468/shareability-memory-attribute

The sharability attribute tells the processor it must do whatever is necessary to allow that data to be shared. What that really means depends on the features of a particular processor.

On a processor with multi-CPU hardware cache coherency; the shareability attribute is a signal to engage the cache coherency logic. For example A57 can maintain cache-coherency of shareable data within the cluster and between clusters if connected via a coherent interconnect.

On a processor without hardware cache coherency , such as Cortex-A8, the only way to share the data is to push it out of the cache as you guessed. On A8 shareable, cacheable memory ends up being treated as un-cached.

Someone, please correct me if I'm wrong - it's so hard to come by definitive and concise statements on the topic.

---

Question: I need to define an MPU region for a QSPI Flash memory. QSPI memory should be configured as Strongly Ordered. I don't really understand why?

The MPU guide above claims at least two points: prevent speculative access and prevent writes from being fragmented (eg interrupted by reading operations).

Speculative memory read may cause high latency or even system error when performed on external memories like SDRAM, or Quad-SPI.

External memories even don't need to be connected to the microcontroller, but its memory range is accessible by speculative read because by default, its memory region is set as Normal.

Speculative access is never made to Strongly Ordered and Device memory areas.

Strongly Ordered memory type is used in memories which need to have each write be a single transaction

For Strongly Ordered memory region CPU waits for the end of memory access instruction.

Finally, I suspect that alignment can be a requirement from the memory side which is adequately represented by a memory type that enforces aligned read/write access.

https://developer.arm.com/documentation/ddi0489/d/memory-system/axim-interface/memory-system-implications-for-axi-accesses

However, Device and Strongly-ordered memory are always Non-cacheable. Also, any unaligned access to Device or Strongly-ordered memory generates alignment UsageFault and therefore does not cause any AXI transfer. This means that the access examples are given in this chapter never show unaligned accesses to Device or Strongly-ordered memory.

---

UsageFault: Without explicit configuration, UsageFault defaults to calling the HardFault handler. Differentiated error handling needs to be enabled in SCB System Handler Control and State Register first:

SCB->SHCSR |= SCB_SHCSR_MEMFAULTENA_Msk // will also be set by HAL_MPU_Enable()
    | SCB_SHCSR_BUSFAULTENA_Msk
    | SCB_SHCSR_USGFAULTENA_Msk;

UsageFault handlers can evaluate UsageFault status register (UFSR) described in https://www.keil.com/appnotes/files/apnt209.pdf .

printf("UFSR : 0x%4x\n", (SCB->CFSR >> 16) & 0xFFFF);