SPRUJ17I March 2022 – August 2025 AM2631 , AM2631-Q1 , AM2632 , AM2632-Q1 , AM2634 , AM2634-Q1
The MPU performs access permission check for each Bus access reaching the MPU and decides to allow the access to pass unmodified further to the target memory if it passes the permission check OR disallow the access and fault the access back to the initiator if it fails the permission check.
Figure 3-7 MPU Top Level DiagramPrivilege ID (PrivID)
Every initiator is associated with an Identifier referred to as Priv ID. See section ISC (Initiator-side Security Control) for how to assign a PrivID to each initiator. This PrivID identifies the controller for privilege purposes and accompanies all bus accesses made on behalf of that controller. That is, when a controller triggers a bus access command, the PrivID is carried alongside the command.
Privilege Level (Priv)
Every initiator access on the input bus is associated with a privilege level. Two privilege levels are supported: supervisor and user. The privilege level is inherited from the code running on the corresponding processor. For example, ARM processor has User mode and Supervisor Mode.
Secure/Non Secure Access
Every initiator is associated with a security level identifier Secure or Non Secure. When an initiator triggers a bus access command, the security level is carried alongside the command. See section ISC (Initiator-side Security Control) for how to assign a security level to each initiator.
Debugger Access
When a JTAG based debugger makes access to a peripheral or Memory through the AHB-Ap port, such an access is qualified by a EMU (Emulator) signal.
MPU Region
Each MPU is associated with multiple MPU regions. Each region of the MPU is programmable. The programming specifies which Initiators are allowed access, the address range where the access is allowed and additional access attributes such as read/Write/execute etc.
A high level view of each MPU region is shown below:

• The start address PROGRAMMABLE_n_START_ADDRESS specifies the start address of the memory protection region ‘n’.
• The End address PROGRAMMABLE_n_END_ADDRESS specifies the end address of the memory protection region ‘n’.
The granularity of the MPU in this device is 1KB. The lower 10 bits of the Programmable start and end address are a don’t care.
Actual MPU_start_address[31:0] = PROGRAMMABLE_n_START_ADDRESS[ 31:10] : 10’b0
Actual MPU_end_address[31:0] = PROGRAMMABLE_n_END_ADDRESS[31:10]:10’b1111111111
• The MPPA(Memory Protection Permission Attribute) register PROGRAMMABLE_n_MPPA specifies the permission attributes for region ‘n’. AID15_0 field (Register bits 25-10) specifies the privID’s for which the rule of this region applies. There is an AID register bit for each possible privID (0 to 15) and an AIDX that covers privIDs not configured. The other bits specify the access attributes such as User Read/Write/Execute or Supervisor ReadWrite/Execute as well as Non secure access and Emulation/Debugger access.
1. The MPU works by first checking the transfer’s privID against the AID settings. The privID is used to lookup the associated AID bit. If the AID bit is 0, then the range does not cover that Initiator/ID and the range is not checked (although other ranges with different AID setting will) for this transfer. If the AID bit is 1, then the range does cover that Initiator/PrivID and the permissions are checked.
2. The transfer secure and debug parameters are checked against the MPPA values to detect an allowed access. The two bits (NS and EMU) provide 3 permission levels.
3. For Non Debugger(Regular Initiator access from within the Device) the read, write and execute permissions are also checked.
| NS | EMU | Description |
|---|---|---|
| 0 | 0 |
Region x is secure without debug: Only secure accesses are allowed. Debug accesses are not allowed. Non-secure accesses are also not allowed |
| 0 | 1 |
Region x is secure with debug: Only secure and debug accesses are allowed. Non-secure accesses are not allowed |
| 1 | - |
Region x is non-secure: All accesses (non-secure, secure and debug) are allowed. |
4. There is a set of permissions for supervisor mode and another for user mode. The “priv” attribute of the transfer determines the mode of access.
The Priv attribute signal on the bus depends on the mode of the CPU making the bus access.
| Bit | Description |
|---|---|
| PROGRAMMABLE_x_MPPA[5] SR | Supervisor may read |
| PROGRAMMABLE_x_MPPA[4] SW | Supervisor may write |
| PROGRAMMABLE_x_MPPA[3] SX | Supervisor may execute |
| PROGRAMMABLE_x_MPPA[2] UR | User may read |
| PROGRAMMABLE_x_MPPA[1] UW | User may write |
| PROGRAMMABLE_x_MPPA[0] UX | User may execute |
5. Each region outputs whether the transfer is allowed or disallowed or don’t care.
The region outputs are aggregated to decide if the access is allowed or disallowed.
The MPU configuration used in this device does not allow access by default (Blocking by default).
In other words the final permission is the lowest of each type of permission from any hit range. (So If a transfer hits 2 regions , one that is rw and another r, the final permission is just r).
Due to MPU architecture limitation, in case of a Cacheable access from R5 CPU, if the cache line(32Byte) access falls in the last 32Bytes of the MPU region, the MPU incorrectly indicates an access fault. Hence it is recommended that the application does not perform a cacheable access on the last 32Bytes of an MPU region. This limitation does not exist for non Cacheable access from R5 or any access from non R5 initiators.