Debugging Non-Secure Code on ARM FVP_MPS2_AEMv8M: Secure-Non-Secure Transition Issues

ARM Cortex-M33 Secure-Non-Secure Transition Failure During Debugging

The core issue revolves around the inability to debug the non-secure (NS) image on the ARM FVP_MPS2_AEMv8M platform, specifically when attempting to step through the non-secure code after setting a breakpoint at the main function. The debugger fails to step into the non-secure code, resulting in an error message: ERROR(CMD440-COR89): ! Stepping failed! Target is currently running. This issue is rooted in the secure-non-secure transition mechanism, which is not properly handled during the debugging process. The secure image (tfm_s.axf) initializes correctly, but the debugger cannot transition to the non-secure image (tfm_ns.axf) due to misconfigured debug settings or improper handling of the entry point and context switching.

The ARM Cortex-M33 processor, which is emulated by the FVP_MPS2_AEMv8M model, implements the ARMv8-M architecture with TrustZone technology. TrustZone divides the system into secure and non-secure states, each with its own memory regions, peripherals, and execution contexts. Debugging such a system requires careful handling of the secure-non-secure transition, as the debugger must be aware of the current state (secure or non-secure) and manage the context switch appropriately. The failure to step into the non-secure code indicates that the debugger is either not recognizing the non-secure context or is unable to handle the transition due to missing or incorrect configuration.

Misconfigured Debugger Settings and Missing Non-Secure Symbol Files

The primary cause of the issue lies in the debugger configuration and the handling of symbol files for the non-secure image. When debugging a TrustZone-enabled system, the debugger must be explicitly informed about the non-secure code’s location and entry point. In the provided scenario, the debugger is launched with the secure image (tfm_s.axf) but does not have access to the non-secure image’s symbol table (tfm_ns.axf). This results in the debugger being unable to resolve the non-secure code’s addresses, leading to the stepping failure.

Additionally, the debugger’s configuration may not account for the secure-non-secure transition, which is a critical aspect of TrustZone systems. The transition from secure to non-secure state involves updating the Vector Table Offset Register (VTOR) and ensuring that the Non-Secure Callable (NSC) region is properly configured. If the debugger is not aware of these changes, it will fail to recognize the non-secure context and will be unable to step through the non-secure code.

Another potential cause is the improper handling of the debugger’s breakpoints. In TrustZone systems, breakpoints must be set in both secure and non-secure contexts, and the debugger must be capable of managing these breakpoints across state transitions. If the breakpoint is only set in the secure context, the debugger will not be able to halt execution in the non-secure context, resulting in the observed stepping failure.

Configuring the Debugger for Secure-Non-Secure Transitions and Adding Non-Secure Symbols

To resolve the issue, the debugger must be properly configured to handle the secure-non-secure transition and to recognize the non-secure code’s symbol table. The following steps outline the necessary actions to achieve this:

1. Launch the Debugger with the Secure Image: Start the debugger with the secure image (tfm_s.axf) as the primary executable. This ensures that the debugger is aware of the secure context and can manage the secure-non-secure transition.

   /usr/local/DS-5_v5.27.1/bin/debugger --cdb-entry "ARM FVP::MPS2_AEMv8M::Bare Metal Debug::Bare Metal Debug::Debug AEMv8M_0" --image "trusted-firmware-m/cmake_build/app/secure_fw/tfm_s.axf"
   

2. Add the Non-Secure Symbol File: Once the debugger is running, add the symbol file for the non-secure image (tfm_ns.axf). This informs the debugger about the non-secure code’s location and allows it to resolve addresses in the non-secure context.

   add-symbol-file trusted-firmware-m/cmake_build/app/tfm_ns.axf
   

3. Set a Breakpoint in the Non-Secure Code: Set a breakpoint at the main function in the non-secure image. This ensures that the debugger will halt execution when the non-secure code is reached.

   b trusted-firmware-m/cmake_build/app/tfm_ns.axf:main
   

4. Run the Debugger: Start execution of the secure image. The debugger will handle the secure-non-secure transition and halt at the breakpoint in the non-secure code.

   c
   

5. Step Through the Non-Secure Code: Once the breakpoint in the non-secure code is hit, you can step through the non-secure code as expected.

   s
   

By following these steps, the debugger will be properly configured to handle the secure-non-secure transition and recognize the non-secure code’s symbol table. This ensures that the debugger can step through the non-secure code without encountering the stepping failure.

Detailed Explanation of the Solution

The solution involves a combination of proper debugger configuration and explicit handling of the secure-non-secure transition. The key aspects of the solution are as follows:

• Debugger Configuration: The debugger must be launched with the secure image as the primary executable. This ensures that the debugger is aware of the secure context and can manage the secure-non-secure transition. The secure image initializes the system and sets up the necessary configurations for the non-secure code to execute.

• Non-Secure Symbol File: Adding the non-secure symbol file (tfm_ns.axf) to the debugger is crucial. This allows the debugger to resolve addresses in the non-secure context and set breakpoints in the non-secure code. Without the non-secure symbol file, the debugger will be unable to recognize the non-secure code’s location and will fail to step through it.

• Breakpoint Management: Setting a breakpoint at the main function in the non-secure code ensures that the debugger will halt execution when the non-secure code is reached. This breakpoint must be set after adding the non-secure symbol file, as the debugger needs to know the address of the main function in the non-secure context.

• Secure-Non-Secure Transition Handling: The debugger must be capable of handling the secure-non-secure transition, which involves updating the Vector Table Offset Register (VTOR) and ensuring that the Non-Secure Callable (NSC) region is properly configured. The debugger’s awareness of the secure and non-secure contexts is essential for successful debugging.

Additional Considerations

• Semihosting Configuration: Ensure that semihosting is properly configured for both secure and non-secure contexts. Semihosting allows the debugger to interact with the host system for input/output operations. If semihosting is not configured correctly, it may interfere with the debugging process.

• Memory Map Configuration: Verify that the memory map is correctly configured for both secure and non-secure regions. The debugger must be aware of the memory regions assigned to each context to properly resolve addresses and manage breakpoints.

• Debugger Version Compatibility: Ensure that the debugger version is compatible with the FVP_MPS2_AEMv8M model and the ARM Cortex-M33 processor. Incompatibilities between the debugger and the target platform can lead to unexpected behavior during debugging.

By addressing these considerations and following the outlined steps, the debugger will be properly configured to handle the secure-non-secure transition and successfully debug the non-secure code on the ARM FVP_MPS2_AEMv8M platform.