ARM Cortex-M33 TrustZone Configuration for WiFi Peripheral Access

The core issue revolves around the use of ARM TrustZone on the LPC55S69 microcontroller, specifically when attempting to configure and use a WiFi peripheral (such as the WiFi10Click board) from the Non-Secure (NS) world. The system operates correctly when the WiFi peripheral is initialized and managed from the Secure (S) world, but hard faults occur when the same operations are performed from the Non-Secure world. This suggests a misconfiguration or misunderstanding of the TrustZone security attribution for peripherals, memory regions, or system resources.

ARM TrustZone divides the system into Secure and Non-Secure worlds, with hardware-enforced isolation between the two. The LPC55S69, based on the ARM Cortex-M33, implements TrustZone by allowing developers to assign security attributes to memory regions, peripherals, and interrupts. When a Non-Secure application attempts to access a Secure resource or violates the security rules, a HardFault is triggered. In this case, the WiFi peripheral or its associated resources (such as GPIO pins, SPI interfaces, or DMA channels) are likely misconfigured, leading to access violations.

The problem is further complicated by the fact that the WiFi peripheral initialization involves multiple hardware components, including GPIOs for pin configuration, SPI or SDIO for communication, and potentially DMA for data transfers. Each of these components must be correctly attributed to the Non-Secure world to allow access from the Non-Secure application. If any of these resources remain Secure or are improperly configured, the system will fault.

Misconfigured Peripheral Attribution and Memory Access Violations

The root cause of the HardFaults lies in the TrustZone configuration of the LPC55S69 microcontroller. The following are the most likely causes of the issue:

  1. Incorrect Peripheral Attribution in the Secure Attribution Unit (SAU): The SAU is responsible for defining the security attributes of memory regions and peripherals. If the WiFi peripheral or its associated resources (such as GPIOs, SPI, or DMA) are not explicitly assigned to the Non-Secure world, any attempt to access them from the Non-Secure application will result in a HardFault. This is a common oversight when transitioning from Secure to Non-Secure world development.

  2. Improper GPIO Configuration for Non-Secure Access: The WiFi10Click board relies on GPIO pins for configuration and control. If these GPIOs are not configured to be accessible from the Non-Secure world, the system will fault when the Non-Secure application attempts to initialize or use them. This includes both the pin muxing configuration and the security attribution of the GPIO peripheral.

  3. SPI or SDIO Interface Security Misconfiguration: The WiFi module communicates with the microcontroller via an SPI or SDIO interface. If the SPI/SDIO peripheral is not assigned to the Non-Secure world, or if its associated DMA channels (if used) are not properly configured, the system will fault during initialization or data transfer.

  4. Missing or Incorrect Non-Secure Callable (NSC) Entries: If the WiFi initialization code relies on Secure world functions (such as low-level hardware initialization routines), these functions must be exposed to the Non-Secure world using Non-Secure Callable (NSC) regions. Without proper NSC entries, the Non-Secure application cannot invoke these functions, leading to a HardFault.

  5. Interrupt Configuration Issues: The WiFi peripheral may generate interrupts that need to be handled in the Non-Secure world. If the interrupts are not correctly attributed to the Non-Secure world or if the Non-Secure vector table is not properly configured, the system will fault when an interrupt occurs.

Configuring TrustZone for Non-Secure WiFi Peripheral Access

To resolve the HardFaults and enable Non-Secure access to the WiFi peripheral, follow these detailed troubleshooting steps and solutions:

Step 1: Verify and Configure the Secure Attribution Unit (SAU)

The SAU is the cornerstone of TrustZone configuration on the LPC55S69. It defines which memory regions and peripherals are Secure or Non-Secure. To ensure the WiFi peripheral and its associated resources are accessible from the Non-Secure world, follow these steps:

  1. Identify the Base Addresses of Relevant Peripherals: Determine the base addresses of the GPIO, SPI/SDIO, and DMA peripherals used by the WiFi module. These addresses are typically found in the microcontroller’s reference manual.

  2. Configure the SAU Regions: Use the SAU to assign the identified peripherals to the Non-Secure world. This involves setting up SAU regions with the appropriate base address, size, and security attribute. For example:

    • GPIO peripheral base address: 0x400F4000, size: 0x1000, attribute: Non-Secure.
    • SPI peripheral base address: 0x40080000, size: 0x1000, attribute: Non-Secure.
    • DMA peripheral base address: 0x400C0000, size: 0x1000, attribute: Non-Secure.

  3. Enable the SAU: After configuring the SAU regions, enable the SAU by setting the appropriate control register bits. This activates the security attributes defined in the SAU.

Step 2: Configure GPIOs for Non-Secure Access

The WiFi10Click board relies on GPIOs for pin configuration and control. To ensure these GPIOs are accessible from the Non-Secure world:

  1. Set GPIO Pin Muxing: Configure the pin muxing registers to assign the appropriate GPIO pins to the WiFi module. This step is independent of TrustZone but is necessary for proper functionality.

  2. Assign GPIO Peripheral to Non-Secure World: Ensure the GPIO peripheral is assigned to the Non-Secure world in the SAU, as described in Step 1.

  3. Verify GPIO Security Attribution: Double-check that the GPIO pins used by the WiFi module are not locked or restricted by any Secure-only configurations.

Step 3: Configure SPI/SDIO and DMA for Non-Secure Access

The SPI/SDIO interface and DMA channels must also be configured for Non-Secure access:

  1. Assign SPI/SDIO Peripheral to Non-Secure World: Ensure the SPI/SDIO peripheral is assigned to the Non-Secure world in the SAU.

  2. Configure DMA Channels: If DMA is used for data transfers, assign the DMA peripheral and the specific channels to the Non-Secure world.

  3. Set Up Non-Secure Interrupts: Configure the interrupts generated by the SPI/SDIO and DMA peripherals to be handled in the Non-Secure world. This involves setting the appropriate bits in the NVIC (Nested Vectored Interrupt Controller) and ensuring the Non-Secure vector table is correctly populated.

Step 4: Implement Non-Secure Callable (NSC) Entries

If the WiFi initialization code relies on Secure world functions, these functions must be exposed to the Non-Secure world using NSC regions:

  1. Identify Secure Functions: Determine which Secure functions are required by the Non-Secure application for WiFi initialization.

  2. Create NSC Regions: Define NSC regions in the Secure world to expose the identified functions. This involves placing the function pointers in an NSC region and ensuring the region is marked as Non-Secure Callable in the SAU.

  3. Invoke Secure Functions from Non-Secure World: Modify the Non-Secure application to call the Secure functions through the NSC entries.

Step 5: Debugging and Validation

After implementing the above steps, validate the configuration and debug any remaining issues:

  1. Use a Debugger: Attach a debugger to the microcontroller and set breakpoints at critical points in the WiFi initialization code. Monitor the system behavior and check for any HardFaults or access violations.

  2. Verify SAU Configuration: Use the debugger to inspect the SAU registers and ensure the security attributes are correctly set.

  3. Check Interrupt Handling: Verify that interrupts are correctly routed to the Non-Secure world and handled by the Non-Secure application.

  4. Test Data Transfers: Perform test data transfers over the WiFi interface to ensure the SPI/SDIO and DMA configurations are correct.

By following these steps, you can resolve the HardFaults and successfully configure the WiFi peripheral for Non-Secure access on the LPC55S69 microcontroller. This approach ensures that the TrustZone security model is correctly implemented, allowing the WiFi module to operate seamlessly in the Non-Secure world while maintaining the isolation and security of the Secure world.

Similar Posts

and Utilizing the TCM Interface on ARM Cortex-R4F Processors

and Utilizing the TCM Interface on ARM Cortex-R4F Processors

BySystem on Chips

ARM Cortex-R4F TCM Interface Configuration and Timing Challenges The Tightly Coupled Memory (TCM) interface on the ARM Cortex-R4F processor is a critical component for achieving high-performance, low-latency memory access in real-time embedded systems. TCMs, including ATCM (Advanced TCM) and BTCM (Base TCM), are designed to provide fast and deterministic access to critical code and data,

Cortex-R52 ECC Calculation: Data vs. Data + Address in TCMs and Cache Memories

Cortex-R52 ECC Calculation: Data vs. Data + Address in TCMs and Cache Memories

BySystem on Chips

ARM Cortex-R52 ECC Implementation for TCMs and Cache Memories The ARM Cortex-R52 processor is widely used in safety-critical applications where error detection and correction are paramount. One of the key features enabling this reliability is Error Correction Code (ECC) for Tightly Coupled Memories (TCMs) and cache memories. ECC is a mechanism that detects and corrects

AHB5 Slave Behavior with HNONSEC Signal: Trust and Security Implications

AHB5 Slave Behavior with HNONSEC Signal: Trust and Security Implications

BySystem on Chips

AHB5 Slave Response to HNONSEC Signal in Trusted and Untrusted Scenarios The behavior of an AHB5 slave when receiving transactions with the HNONSEC signal depends on whether the slave is a trusted peripheral or not, as well as the value of the HNONSEC signal itself. The HNONSEC signal is a critical component of the ARM

ARM Cortex-A35 128-bit Atomic Access Limitations and Workarounds

ARM Cortex-A35 128-bit Atomic Access Limitations and Workarounds

BySystem on Chips

ARM Cortex-A35 128-bit Atomic Access Limitations The ARM Cortex-A35, based on the ARMv8.0-A architecture, is a highly efficient processor designed for low-power applications. However, one of its limitations is the lack of native support for 128-bit atomic read/write operations between multiple cores. This limitation is rooted in the ARMv8-A architecture’s atomicity model, which only guarantees

Debugging Cortex-M3 Debugger Issues: PORESETn, SYSRESETn, and DAPRESETn Signal Requirements

Debugging Cortex-M3 Debugger Issues: PORESETn, SYSRESETn, and DAPRESETn Signal Requirements

BySystem on Chips

Understanding the Role of PORESETn, SYSRESETn, and DAPRESETn in Cortex-M3 Debugging The Cortex-M3 processor, as outlined in the Technical Reference Manual (TRM) r2p0 (Issue H), incorporates three distinct reset signals: PORESETn, SYSRESETn, and DAPRESETn. Each of these signals serves a unique purpose in the reset and debugging architecture of the processor. PORESETn, or Power-On Reset,

Dual-Core Cortex-A7 L2 Cache Partitioning and Lockdown Challenges

Dual-Core Cortex-A7 L2 Cache Partitioning and Lockdown Challenges

BySystem on Chips

ARM Cortex-A7 Shared L2 Cache Configuration and Real-Time Performance Optimization The ARM Cortex-A7 processor, often used in dual-core configurations, is designed for energy efficiency and is commonly found in embedded systems requiring a balance between performance and power consumption. One of the key features of the Cortex-A7 is its shared L2 cache, which is typically

Leave a Reply

Your email address will not be published. Required fields are marked *