Non-Secure UART1 Configuration Hardfault on ARM Musca-A1

ARM Cortex-M33 SAU and PPC Configuration for Non-Secure UART1 Access

The ARM Musca-A1 platform, based on the ARM Cortex-M33 processor, implements a TrustZone security architecture that divides the system into Secure and Non-Secure worlds. Configuring peripherals like UART1 for Non-Secure access requires careful manipulation of the Security Attribution Unit (SAU) and the Peripheral Protection Controller (PPC). The SAU defines memory regions and peripherals as Secure or Non-Secure, while the PPC enforces access permissions based on these definitions. In this case, the user attempted to configure UART1 for Non-Secure access but encountered a hardfault when accessing UART1 registers such as UART1IBRD. The hardfault was accompanied by specific status flags in the Configurable Fault Status Register (CFSR), HardFault Status Register (HFSR), and Secure Fault Status Register (SFSR).

The hardfault indicates a violation of the security model, likely due to incorrect SAU or PPC configuration. The Cortex-M33’s TrustZone implementation requires that both the SAU and PPC are properly configured to grant Non-Secure access to peripherals. The SAU must define the memory region containing UART1 as Non-Secure, and the PPC must explicitly permit Non-Secure access to UART1. Additionally, the system must ensure that no Secure code or configuration is inadvertently interfering with the Non-Secure world’s access to UART1.

The user’s initial assumption about requiring SAU and PPC configuration was correct, but the hardfault suggests that either the SAU or PPC settings were incomplete or misconfigured. Furthermore, the presence of pre-existing code in Flash memory before loading custom code into SRAM introduced additional complexity. This pre-existing code might have interfered with the SAU or PPC configuration, leading to the hardfault. Resolving this issue requires a detailed understanding of the SAU, PPC, and TrustZone security model, as well as careful debugging to identify and correct the configuration errors.

SAU Region Misconfiguration and PPC Access Permission Issues

The primary cause of the hardfault is likely a misconfiguration of the SAU or PPC. The SAU divides the memory map into regions and assigns each region as Secure or Non-Secure. For UART1 to be accessible from the Non-Secure world, the SAU must define the memory region containing UART1 as Non-Secure. If the SAU configuration is incorrect or incomplete, attempts to access UART1 from the Non-Secure world will result in a SecureFault or HardFault.

The PPC, on the other hand, enforces access permissions for peripherals based on their security attributes. Even if the SAU correctly defines UART1 as Non-Secure, the PPC must also be configured to permit Non-Secure access to UART1. The PPC configuration is typically done through registers such as AHBNSPPCEXP0, which control access permissions for specific peripherals. If the PPC is not configured to allow Non-Secure access to UART1, any attempt to access UART1 registers will result in a HardFault.

Another potential cause is the presence of pre-existing code in Flash memory. This code might have configured the SAU or PPC in a way that conflicts with the user’s intended configuration. For example, the pre-existing code might have defined UART1 as Secure or might have locked the PPC configuration, preventing further modifications. This would explain why the user encountered a hardfault despite correctly configuring the SAU and PPC in their custom code.

Finally, the hardfault might be caused by incorrect initialization or timing issues. The SAU and PPC configurations must be applied in a specific order and at the right time during the boot process. If the configurations are applied too early or too late, they might not take effect or might be overwritten by other code. Additionally, the system must ensure that no Secure code is accessing UART1 while it is being configured for Non-Secure access, as this could lead to race conditions or conflicts.

Correct SAU and PPC Configuration for Non-Secure UART1 Access

To resolve the hardfault and successfully configure UART1 for Non-Secure access, follow these steps:

First, verify the SAU configuration. The SAU must define the memory region containing UART1 as Non-Secure. This is done by setting the appropriate bits in the SAU Region Number Register (SAU_RNR) and SAU Region Base Address Register (SAU_RBAR). The SAU_RNR selects the region to be configured, while the SAU_RBAR defines the base address and attributes of the region. Ensure that the region containing UART1 is marked as Non-Secure and that the region size is sufficient to cover all UART1 registers.

Next, configure the PPC to permit Non-Secure access to UART1. This is done by setting the appropriate bits in the AHBNSPPCEXP0 register. The AHBNSPPCEXP0 register controls access permissions for peripherals in the AHB expansion 0 space, which includes UART1. Set the bit corresponding to UART1 to allow Non-Secure access. Additionally, ensure that no other PPC registers are restricting access to UART1.

If pre-existing code in Flash memory is interfering with the SAU or PPC configuration, modify the boot process to ensure that the custom code in SRAM is executed first. This can be done by adjusting the vector table or bootloader to prioritize the SRAM code. Alternatively, disable or overwrite the pre-existing code in Flash memory to prevent it from interfering with the SAU and PPC configurations.

Finally, ensure that the SAU and PPC configurations are applied at the correct time during the boot process. The SAU and PPC configurations should be applied after the system has initialized but before any Non-Secure code attempts to access UART1. Use memory barriers or synchronization instructions to ensure that the configurations take effect before proceeding.

By carefully configuring the SAU and PPC, and ensuring that no conflicting code is present, you can successfully configure UART1 for Non-Secure access and avoid hardfaults. The following table summarizes the key registers and their configurations:

In conclusion, configuring UART1 for Non-Secure access on the ARM Musca-A1 platform requires careful attention to the SAU and PPC configurations. Misconfigurations or conflicts with pre-existing code can lead to hardfaults, but by following the steps outlined above, you can successfully enable Non-Secure access to UART1 and avoid these issues.