Speculative access and STM32H7 Memory Protection Unit

[JRS]

After seeing the MOOC about the MPU Usage I am wondering about the speculative access reads. From the video it seemed, that they could occur to any random location unless that area was configured as strongly ordered or device memory. What about the areas that are not defined in the mpu. Do I need to specifically disable those regions (e.g. unused fmc or ospi peripherals)? I would guess not, as it is not done in any example.

To summarize the questions:

a) If I use the MPU, can the speculative accesses be made to any address outside of the regions I declared i the mpu settings?

b) What restricts these speculative accesses (except for mpu regions - strongly ordered/ device memory)?

[SofLit · Accepted solution]

Hello,

Please refer to the AN4861 "LCD-TFT display controller (LTDC) on STM32 MCUs" / Section 4.6 Special recommendations for Cortex-M7 (STM32F7/H7).

It may answer your questions.

[waclawek.jan]

Depending on MPU_CTRL.PRIVDEFENA, access to regions not defined in MPU may either throw fault, or they may behave according to the background memory map (which is identical to the default memory map).

The speculative accesses are not made entirely randomly, that would make no sense and would be counter productive; they are made by the cache controller in conjunction with line fills/eviction, and perhaps by the fetch unit to speculatively prefetch branches. It means, they all will be relatively closely located to recent explicit accesses.

JW

[JRS]

To summarize: While it makes sense that the access adresses will be close, this seems to be a problem near the borders. From the  AN4861:  MPU must be configured according to the size of the memory used by the application. • The MPU attributes of the unused regions must be configured to strongly ordered execute never (XN). For example, for the Quad-SPI, if an 8-Mbyte memory is connected, the remaining 248-Mbyte unused space (from a total 256-Mbyte addressable space) must be set to strongly ordered XN. See example in Section 6.2.7. 

Also the PM0253 is of help, since in the current Reference Manual the MPU Registers are not covered.

[waclawek.jan]

> Also the PM0253 is of help, since in the current Reference Manual the MPU Registers are not covered.

This is deliberate division amongst the manuals: the RM generally deals only with those details of the design which are provided by ST, whereas PM0253 (and other "Programming Manuals" are for the information on the ARM-provided processor core. MPU is part of the processor (in the same way as NVIC is).

JW