Secure and Non-Secure World MPU Configuration Conflicts on Cortex-M33

Secure and Non-Secure MPU Configuration Leading to MemManage Fault Escalation

The issue at hand involves a Cortex-M33 microcontroller unit (MCU) running FreeRTOS-MPU in the non-secure world with the Non-Secure Memory Protection Unit (MPU_NS) enabled, while executing trusted code in the secure world with the Secure Memory Protection Unit (MPU_S) disabled. The problem manifests when the Secure Attribution Unit (SAU) is enabled alongside MPU_NS, leading to a Secure HardFault during the execution of the vRestoreContextOfFirstTask function. Specifically, a load instruction at address 0x08041030 triggers a MemManage Fault, which escalates to a HardFault. The fault occurs despite the MPU_NS configuration permitting read and write access to the memory location being accessed.

The fault is indicated by the HardFault Status Register (HFSR) value of 0x40000000, which signifies an escalated exception. The Configurable Fault Status Register for the non-secure world (CFSR_NS) shows a value of 0x00000082, confirming a MemManage Fault. The MemManage Fault Address Register (MMFAR) points to 0x2002b460, the exact address being accessed by the load instruction. This address falls within a region configured in MPU_NS to allow read and write access at any privilege level, raising questions about the interaction between SAU and MPU_NS configurations.

SAU and MPU_NS Interaction Causing Memory Access Violations

The root cause of the issue lies in the interaction between the Secure Attribution Unit (SAU) and the Non-Secure Memory Protection Unit (MPU_NS). The SAU is responsible for defining the memory regions accessible to the non-secure world, while the MPU_NS enforces access permissions within those regions. When both SAU and MPU_NS are enabled, the system must ensure that the memory access permissions defined by MPU_NS do not conflict with the secure world’s memory protection mechanisms.

In this case, the SAU configuration may be restricting access to certain memory regions that MPU_NS assumes are accessible. The load instruction at 0x08041030 attempts to read from 0x2002b460, which is permitted by MPU_NS but may be restricted by the SAU. This discrepancy leads to a MemManage Fault. Additionally, the Secure HardFault indicates that the fault originated in the secure world, suggesting that the SAU’s restrictions are being enforced even when the non-secure world attempts to access memory.

Another potential cause is the timing of MPU_NS enabling and the subsequent memory access. The vRestoreContextOfFirstTask function enables MPU_NS and immediately attempts to access memory. If the MPU_NS configuration is not fully applied or if there is a delay in the enforcement of the new memory protection rules, the memory access could trigger a fault. The presence of Data Synchronization Barrier (DSB) and Instruction Synchronization Barrier (ISB) instructions in the code suggests that the developer was aware of potential timing issues, but the fault still occurs, indicating a deeper configuration problem.

Resolving SAU and MPU_NS Configuration Conflicts

To resolve the issue, the following steps should be taken to ensure proper configuration and interaction between SAU and MPU_NS:

1. Review SAU Configuration: Verify that the SAU configuration does not restrict access to memory regions that MPU_NS assumes are accessible. The SAU should be configured to allow non-secure access to all memory regions that MPU_NS is configured to protect. This includes ensuring that the base address and limit of each SAU region align with the corresponding MPU_NS regions.

2. Check MPU_NS Region Overlaps: Ensure that there are no overlaps between MPU_NS regions and secure memory regions defined by the SAU. Overlapping regions can lead to unexpected access violations. Each MPU_NS region should be carefully defined to avoid conflicts with secure memory.

3. Verify MPU_NS Permissions: Double-check the access permissions defined in MPU_NS to ensure they match the intended memory access patterns. The permissions should allow read and write access to all memory regions that the non-secure world needs to access, while still enforcing security boundaries.

4. Add Additional Synchronization Barriers: Although DSB and ISB instructions are present, additional synchronization barriers may be required to ensure that the MPU_NS configuration is fully applied before memory access is attempted. Inserting additional DSB and ISB instructions after enabling MPU_NS can help prevent timing-related faults.

5. Debug Secure HardFault: Use the Secure HardFault handler to gather more information about the fault. The handler should capture the stack frame, fault status registers, and other relevant information to help diagnose the exact cause of the fault. This information can be used to refine the SAU and MPU_NS configurations.

6. Test with MPU_S Enabled: As a diagnostic step, enable MPU_S and configure it to protect secure memory regions. This can help identify any conflicts between the secure and non-secure MPUs. If the fault persists, it may indicate a more fundamental issue with the memory protection configuration.

7. Consult ARM Documentation: Review the ARM Cortex-M33 Technical Reference Manual (TRM) and the ARMv8-M Architecture Reference Manual for detailed information on SAU and MPU configuration. These documents provide guidance on configuring memory protection units and handling faults.

By following these steps, the conflict between SAU and MPU_NS can be resolved, ensuring that memory access in the non-secure world does not trigger unexpected faults. Proper configuration and synchronization are key to achieving reliable operation in a dual-world environment.

Detailed Analysis of MPU_NS and SAU Configuration

To further understand the issue, let’s analyze the MPU_NS and SAU configurations in detail. The MPU_NS is configured with several regions, including region 4, which allows read and write access to the memory range 0x200274a0 to 0x2002b4bf. This region includes the address 0x2002b460, which is accessed by the load instruction that triggers the fault. The MPU_NS configuration for region 4 is as follows:

• MPU_RBAR: 0x200274a2
  • XN: Execute Never (0)
  • AP: Access Permissions (0x1) – Privileged and Unprivileged Read/Write
  • SH: Shareable (0)
  • BASE: Base Address (0x200274a0)
• MPU_RLAR: 0x2002b4a1
  • EN: Region Enabled (1)
  • AttrIndx: Attribute Index (0)
  • PXN: Privileged Execute Never (0)
  • LIMIT: Limit Address (0x2002b4a0)

This configuration should allow the non-secure world to read and write to the memory range 0x200274a0 to 0x2002b4bf. However, the SAU may be restricting access to this region, causing the MemManage Fault.

The SAU configuration is not provided in the discussion, but it is crucial to ensure that the SAU allows non-secure access to the memory regions defined in MPU_NS. The SAU defines the memory regions that are accessible to the non-secure world, and any restrictions imposed by the SAU will override the permissions defined by MPU_NS.

Conclusion

The issue of Secure HardFaults occurring when enabling both SAU and MPU_NS on a Cortex-M33 MCU is a complex problem that requires careful analysis of the memory protection configurations. By reviewing the SAU and MPU_NS configurations, ensuring proper synchronization, and debugging the Secure HardFault, the conflict can be resolved. Proper configuration of memory protection units is essential for achieving reliable operation in a dual-world environment, where secure and non-secure worlds coexist. Following the steps outlined in this guide will help identify and resolve the configuration issues, ensuring that the system operates as intended.