SAU Region Configuration Mismatch and Hard Fault During Disabling
The Secure Attribution Unit (SAU) is a critical component in ARM Cortex-M processors with TrustZone support, enabling the partitioning of memory into secure and non-secure regions. The SAU configuration process involves setting up the number of regions, their base addresses, limits, and security attributes. However, improper SAU configuration can lead to hard faults, simulation failures, and unexpected behavior during runtime. One common issue arises when the number of regions specified in the software exceeds the hardware’s supported limit, leading to configuration mismatches. Additionally, disabling the SAU without proper handling of the ALLNS (All Non-Secure) bit can trigger hard faults, especially when relying on the Implementation Defined Attribution Unit (IDAU) for secure/non-secure partitioning.
The core problem in this scenario stems from two interrelated issues: a mismatch between the number of SAU regions configured in software and the hardware’s capabilities, and improper handling of the SAU disable sequence. The SAU is designed to support a limited number of regions, typically 4 or 8, depending on the specific Cortex-M implementation. When the software attempts to configure more regions than the hardware supports, the excess configurations are ignored, leading to incomplete or incorrect memory partitioning. Furthermore, disabling the SAU without ensuring that the ALLNS bit is correctly set can cause the processor to misinterpret memory access permissions, resulting in hard faults.
Hardware-Software Region Mismatch and ALLNS Bit Misconfiguration
The primary cause of the SAU configuration failure is the mismatch between the number of regions specified in the software and the hardware’s actual capabilities. In this case, the software attempted to configure 8 regions, while the hardware only supported 4. This discrepancy arises when the software development environment, such as the partition file or configuration scripts, does not accurately reflect the hardware’s limitations. The SAU registers, including the Region Number Register (RNR), Region Base Address Register (RBAR), and Region Limit Address Register (RLAR), are designed to handle a specific number of regions. Writing to these registers beyond the hardware’s supported limit results in undefined behavior, as the excess writes are ignored or overwrite previous configurations.
Another critical factor is the handling of the ALLNS bit in the SAU Control Register (SAU->CTRL). The ALLNS bit determines whether all memory is treated as non-secure when the SAU is disabled. If the SAU is disabled without setting the ALLNS bit correctly, the processor may attempt to access secure memory regions without the proper permissions, triggering a hard fault. This issue is particularly pronounced when the IDAU is used to define secure/non-secure memory regions, as the IDAU’s behavior depends on the SAU’s state and the ALLNS bit’s configuration.
The hard fault during simulation is a direct consequence of these misconfigurations. When the SAU is disabled, the processor relies on the IDAU to determine memory access permissions. If the ALLNS bit is not set, the IDAU may incorrectly classify memory regions, leading to access violations. Additionally, the mismatch between the number of configured regions and the hardware’s capabilities can cause the SAU to fail silently, leaving some memory regions improperly secured or non-secured.
Verifying SAU Configuration and Correcting Region Mismatches
To resolve the SAU configuration failure and hard fault issues, a systematic approach is required to verify the SAU settings, correct region mismatches, and ensure proper handling of the ALLNS bit. The following steps outline the troubleshooting process:
Step 1: Verify Hardware-Supported SAU Regions
The first step is to confirm the number of SAU regions supported by the hardware. This information is typically available in the processor’s technical reference manual or datasheet. Once the hardware’s capabilities are known, update the software configuration to match the supported number of regions. In this case, the software should be modified to configure only 4 regions instead of 8.
Step 2: Validate SAU Register Settings
After ensuring that the number of configured regions matches the hardware’s capabilities, validate the SAU register settings. This involves reading back the RNR, RBAR, and RLAR registers to confirm that the values written during initialization are correctly reflected. Use a debugger or simulation environment to inspect the register values and verify that each region’s base address, limit address, and security attributes are set as intended.
Step 3: Implement Proper SAU Disable Sequence
To prevent hard faults when disabling the SAU, ensure that the ALLNS bit is set correctly in the SAU->CTRL register. The ALLNS bit should be set to 1 before disabling the SAU, ensuring that all memory is treated as non-secure when the SAU is inactive. This step is crucial when relying on the IDAU for secure/non-secure memory partitioning, as it prevents access violations during the transition.
Step 4: Debug Hard Faults Using Exception Handlers
If hard faults persist, use the processor’s exception handling mechanisms to diagnose the issue. Configure the fault handlers to capture the fault status registers, including the Hard Fault Status Register (HFSR), Memory Management Fault Status Register (MMFSR), and Bus Fault Status Register (BFSR). Analyze the fault information to identify the root cause, such as unauthorized memory access or invalid memory addresses.
Step 5: Update RTL and Simulation Environment
In cases where the hardware’s RTL (Register Transfer Level) implementation does not match the expected behavior, update the RTL to reflect the correct number of supported SAU regions. Ensure that the simulation environment accurately models the hardware’s capabilities, including the SAU and IDAU behavior. This step is essential for validating the software’s behavior in a simulated environment before deploying it on actual hardware.
Step 6: Test with IDAU-Only Configuration
To run the application without the SAU, configure the IDAU to define secure and non-secure memory regions. Ensure that the ALLNS bit is set to 1 in the SAU->CTRL register, effectively disabling the SAU and relying solely on the IDAU for memory partitioning. Test the application to verify that it operates correctly without triggering hard faults or access violations.
By following these steps, the SAU configuration failure and hard fault issues can be effectively resolved. Ensuring that the software accurately reflects the hardware’s capabilities, properly handling the ALLNS bit, and validating the SAU register settings are key to achieving reliable and secure memory partitioning in ARM Cortex-M processors with TrustZone support.
