You copied the Doc URL to your clipboard.

Why does the Cortex-M7 initiate AXIM read accesses to memory addresses that do not fall under a defined MPU region?

Article ID: 146793866

Published date: 30 November 2017

Last updated: -

Applies to: Cortex-M7

Problem/Question

Why does the Cortex-M7 processor initiate AXIM read accesses to memory addresses that are not in any defined MPU region?

Scenario

Intended audience:

This article is intended for software developers who see unexpected, random-occurring AXI Master (AXIM) read accesses to memory regions that are undefined by the Memory Protection Unit (MPU).

The Cortex-M7 processor behaviour addressed in this article is as follows:

  • An AXIM read access is initiated, which targets a memory address that is not being explicitly accessed by software.

  • The memory address, which the unexpected AXIM read access targets, does not fall into any defined MPU region.

  • There is no processor fault, irrespective of the response that the memory system gives to the unexpected AXIM read access.

This behaviour can occur under the following circumstances:

  • Both the MPU and data cache are enabled.

  • There are memory addresses that none of the defined MPU regions cover.

  • The default memory map is not being used as a background MPU region.

This behaviour can be observed on the Cortex-M7 versions up to r1p1, and might be changed in future versions of Cortex-M7.

Answer

Regardless of being a speculative access or not, most read accesses initiated on the AXIM are prevented if those accesses are not targeting any defined MPU region, and the default memory map is not being used as a background MPU region:

  • Data read accesses are prevented, because non-defined regions are treated as Non-Accessible.

  • Instruction fetches are prevented, because non-defined regions are treated as eXecute Never (XN).

However, read accesses initiated by a PLD (Preload Data) instruction are only prevented if the data cache is disabled or if the memory address is Non-Cacheable. In this case, the Non-Accessible and XN attributes are ignored. Therefore, a read access initiated by a PLD instruction will not be prevented if the access is not targeting any defined MPU region, unless the memory address is Non-Cacheable in the default memory map, or the data cache is disabled.

There is a rare case, where the user does not have any PLD instruction in their software code, but due to a mispredicted branch, the processor fetches in some random data that appears to be a PLD instruction, and then it gets speculatively executed.

The user will therefore see a data read access on the AXIM to an address that is not mapped to any MPU regions, if all of the following are true:

  • The data cache is enabled.

  • The processor fetches in some random data due to a mispredicted branch, where the random data happens to be the opcode of a PLD instruction.

  • The address targeted by the PLD is unmapped by the MPU. The default memory map is not being used as a background MPU region, but the address in the default memory map is Cacheable.

If the system, in which the processor is integrated in, requires the processor not to access certain memory addresses, then leaving those memory addresses unmapped by the MPU is not a guaranteed way to prevent the case of the speculatively executed PLD instructions. Therefore, there is still a possibility for those memory addresses in question to be accessed.

Workaround

As previously described:

  • Data read accesses are prevented by the memory address being Non-Accessible.

  • Instruction fetches are prevented by the memory address being XN.

  • Data preloads are prevented by the memory address being Non-Cacheable.

Therefore, the only fully reliable way to prevent accesses to certain memory regions is explicitly setting MPU regions with the following attributes:

  • MPU_RASR.XN = 1’b1 (XN)

  • MPU_RASR.AP = 3’b000 (Non-Accessible)

  • MPU_RASR.C = 1’b0 (Non-Cacheable)

To avoid using more than one MPU region for this purpose, the suggested workaround is to perform both of the following steps:

  • Set up MPU region 0 as a 4GB background region with the above attributes.

  • Set up all the accessible memory regions as higher number MPU regions, which will overwrite the region 0 attributes.

Example

N/A

Related Information

N/A

Was this page helpful? Yes No