ARM Cortex-M55 TrustZone HardFault During Secure-to-Secure Firmware Jump
The issue at hand involves a HardFault occurring during the transition from one secure firmware to another on an ARM Cortex-M55 processor with TrustZone enabled. The transition is initiated by jumping to a new vector table, where the reset handler of the next-level secure software is located. The HardFault is observed when running the firmware without a debugger, but the issue does not manifest when debugging with a Lauterbach debugger. This discrepancy suggests a timing or state-related issue that is masked by the debugger’s intervention.
The Cortex-M55 processor, with its TrustZone security extension, introduces additional complexity in managing secure and non-secure states. The transition between secure firmware levels requires careful handling of the processor’s state, including the stack pointers, vector tables, and interrupt settings. The HardFault indicates that the processor is encountering an invalid state or an unexpected condition during the transition.
The transition process involves setting up the new vector table, which includes the stack pointer and the reset handler. The stack pointer is the first element of the vector table, and the reset handler is the second element. The jump address is the address of the new vector table, and the reset handler is located at an offset of 4 bytes from this address. The HardFault suggests that the processor is unable to correctly handle the transition, possibly due to an incorrect setup of the vector table, stack pointers, or interrupt settings.
Misconfigured Vector Table and Stack Pointer Initialization
One of the primary causes of the HardFault during the secure-to-secure firmware transition is a misconfigured vector table or incorrect stack pointer initialization. The vector table in ARM Cortex-M processors is a critical data structure that defines the initial stack pointer and the exception handlers, including the reset handler. If the vector table is not correctly set up, the processor may attempt to use an invalid stack pointer or jump to an incorrect reset handler, leading to a HardFault.
In the Cortex-M55 with TrustZone, the vector table must be properly configured for both secure and non-secure states. The secure vector table must be correctly aligned and located in a memory region that is accessible in the secure state. If the vector table is not aligned to the required boundary (typically 512 bytes), the processor may not be able to correctly interpret the vector table entries, leading to a HardFault.
Another potential cause is the incorrect initialization of the Main Stack Pointer (MSP) and Process Stack Pointer (PSP). The MSP is used in the handler mode, while the PSP is used in the thread mode. During the transition to the next-level secure software, the stack pointers must be correctly initialized to point to valid memory regions. If the stack pointers are not correctly set, the processor may attempt to access invalid memory, leading to a HardFault.
Additionally, the NVIC (Nested Vectored Interrupt Controller) must be properly configured before the transition. Interrupts should be disabled during the transition to prevent any unexpected exceptions from occurring. If interrupts are not disabled, an interrupt may occur during the transition, leading to an inconsistent state and a HardFault.
Proper Vector Table Setup and Secure State Transition Procedure
To resolve the HardFault issue during the secure-to-secure firmware transition, a detailed and methodical approach is required. The following steps outline the necessary procedures to ensure a successful transition:
1. Vector Table Configuration and Alignment:
The vector table must be correctly aligned and located in a memory region that is accessible in the secure state. The alignment requirement for the vector table is typically 512 bytes, and the table must be located at an address that is a multiple of this alignment. The vector table should be defined in the linker script to ensure it is placed at the correct memory location. The first entry in the vector table should be the initial value of the MSP, and the second entry should be the address of the reset handler.
2. Stack Pointer Initialization:
Before jumping to the next-level secure software, the MSP and PSP must be correctly initialized. The MSP should be set to the initial stack pointer value defined in the vector table. If the next-level software uses the PSP, it should also be initialized to a valid memory region. The stack pointers should be set using the MSR instruction, ensuring that they point to valid memory regions that are accessible in the secure state.
3. Disabling Interrupts:
Interrupts should be disabled before the transition to prevent any unexpected exceptions from occurring. The NVIC should be configured to disable all interrupts using the CPSID instruction. This ensures that no interrupts are pending or active during the transition, preventing any potential race conditions or inconsistent states.
4. Setting the New Vector Table:
The new vector table must be set before jumping to the next-level secure software. The vector table offset register (VTOR) should be updated to point to the new vector table. The VTOR is a register in the System Control Block (SCB) that defines the base address of the vector table. The VTOR should be set using the LDR and STR instructions, ensuring that the new vector table is correctly recognized by the processor.
5. Clearing Current Stack Pointers:
The current MSP and PSP should be cleared before setting the new stack pointers. This ensures that there are no residual values in the stack pointers that could cause issues during the transition. The stack pointers can be cleared using the MSR instruction, setting them to a known value (e.g., zero) before initializing them to the new values.
6. Jumping to the Next-Level Secure Software:
The final step is to jump to the next-level secure software. This is done by loading the address of the reset handler from the new vector table and branching to it. The address of the reset handler is located at an offset of 4 bytes from the base address of the vector table. The branch can be performed using the BX instruction, ensuring that the processor correctly transitions to the new secure software.
7. Enabling Interrupts:
After the transition is complete, interrupts can be re-enabled using the CPSIE instruction. This allows the next-level secure software to handle interrupts as required. The NVIC should be configured to enable the necessary interrupts, ensuring that the system operates correctly in the secure state.
8. Debugging and Verification:
The transition process should be thoroughly tested and verified using a debugger. The Lauterbach debugger can be used to step through the transition process, ensuring that each step is correctly executed. The debugger can also be used to inspect the state of the processor, including the stack pointers, vector table, and interrupt settings, to ensure that they are correctly configured.
By following these steps, the HardFault issue during the secure-to-secure firmware transition can be resolved. The key is to ensure that the vector table is correctly configured, the stack pointers are properly initialized, and interrupts are disabled during the transition. Additionally, the transition process should be thoroughly tested and verified using a debugger to ensure that the system operates correctly in the secure state.
Conclusion
The HardFault issue during the secure-to-secure firmware transition on the ARM Cortex-M55 with TrustZone is a complex problem that requires careful handling of the processor’s state. The issue is likely caused by a misconfigured vector table, incorrect stack pointer initialization, or improper interrupt handling. By following the detailed troubleshooting steps outlined above, the issue can be resolved, ensuring a successful transition to the next-level secure software. The key is to methodically configure the vector table, initialize the stack pointers, disable interrupts, and verify the transition process using a debugger. With these steps, the system can operate reliably in the secure state, preventing HardFaults and ensuring the correct execution of the secure firmware.
