Non-Secure HardFault Handler Trapping and EXC_RETURN Value Analysis
When dealing with ARM Cortex-M processors that implement the ARMv8-M architecture, one of the critical aspects of debugging and fault handling is understanding the behavior of the EXC_RETURN value, especially in the context of secure and non-secure states. The EXC_RETURN value is a special code that the processor uses to determine the state to return to after an exception handler completes. In the scenario where a HardFault occurs in the non-secure state and is trapped by the secure HardFault handler, the EXC_RETURN value can sometimes be ambiguous, making it difficult to determine the exact state of the system at the time of the fault.
The EXC_RETURN value is a 32-bit value that encodes several pieces of information, including the stack pointer used (MSP or PSP), the security state (secure or non-secure), and the execution mode (thread or handler). In the case of a HardFault occurring in the non-secure state, the EXC_RETURN value should ideally provide enough information to determine whether the fault occurred in non-secure unprivileged thread mode with PSP_NS or in non-secure privileged thread mode with MSP_NS. However, in some cases, the EXC_RETURN value may not provide sufficient differentiation, leading to ambiguity in the fault handling process.
This ambiguity can be particularly problematic when trying to debug complex systems where the distinction between privileged and unprivileged modes, as well as the stack pointer used, is critical for understanding the root cause of the fault. Without this information, it becomes challenging to determine the exact context in which the fault occurred, making it difficult to implement effective fault recovery mechanisms.
CONTROL_NS.SPSEL and EXC_RETURN Interpretation
The key to resolving the ambiguity in the EXC_RETURN value lies in understanding the role of the CONTROL_NS.SPSEL bit. The CONTROL_NS register is a non-secure control register that governs the behavior of the non-secure state, including the selection of the stack pointer. The SPSEL bit in the CONTROL_NS register determines whether the non-secure state uses the Main Stack Pointer (MSP_NS) or the Process Stack Pointer (PSP_NS).
When a HardFault occurs in the non-secure state, the EXC_RETURN value will indicate that the fault occurred in the non-secure state, but it may not differentiate between privileged and unprivileged modes. However, by examining the CONTROL_NS.SPSEL bit, it is possible to determine which stack pointer was in use at the time of the fault. If the SPSEL bit is set to 0, it indicates that the MSP_NS was in use, suggesting that the fault occurred in non-secure privileged thread mode. Conversely, if the SPSEL bit is set to 1, it indicates that the PSP_NS was in use, suggesting that the fault occurred in non-secure unprivileged thread mode.
This distinction is crucial for accurately diagnosing the cause of the fault. For example, if the fault occurred in non-secure privileged thread mode, it may indicate an issue with the system’s privileged operations, such as an invalid memory access or an illegal instruction. On the other hand, if the fault occurred in non-secure unprivileged thread mode, it may indicate an issue with the application code, such as a stack overflow or an invalid function call.
In addition to the CONTROL_NS.SPSEL bit, it is also important to examine the stacked registers, particularly the Program Counter (PC) and the Stack Pointer (SP), to determine the exact instruction that caused the fault. The stacked PC will point to the instruction that was executing at the time of the fault, while the stacked SP will provide information about the state of the stack at the time of the fault. By combining this information with the CONTROL_NS.SPSEL bit, it is possible to reconstruct the exact context in which the fault occurred, allowing for more effective debugging and fault recovery.
Implementing Secure and Non-Secure HardFault Handlers with Context Awareness
To effectively handle HardFaults in a system that implements both secure and non-secure states, it is essential to implement HardFault handlers that are context-aware. This means that the handlers should be able to determine the exact state of the system at the time of the fault, including the security state, the execution mode, and the stack pointer used. This can be achieved by combining the information provided by the EXC_RETURN value, the CONTROL_NS.SPSEL bit, and the stacked registers.
In the case of a secure HardFault handler, the handler should first examine the EXC_RETURN value to determine whether the fault occurred in the secure or non-secure state. If the fault occurred in the non-secure state, the handler should then examine the CONTROL_NS.SPSEL bit to determine which stack pointer was in use at the time of the fault. This information can then be used to determine the exact context in which the fault occurred, allowing the handler to take appropriate action.
For example, if the fault occurred in non-secure privileged thread mode, the handler may need to perform additional checks to determine whether the fault was caused by an invalid memory access or an illegal instruction. If the fault occurred in non-secure unprivileged thread mode, the handler may need to examine the application code to determine whether the fault was caused by a stack overflow or an invalid function call.
In addition to examining the CONTROL_NS.SPSEL bit and the stacked registers, the secure HardFault handler should also consider the possibility of nested exceptions. In some cases, a HardFault may occur while the processor is already handling another exception. In such cases, the handler must be careful to preserve the context of the original exception while handling the HardFault. This can be achieved by saving the context of the original exception before handling the HardFault and then restoring the context once the HardFault has been handled.
Finally, it is important to note that the secure HardFault handler should be designed to handle faults in both the secure and non-secure states. This means that the handler must be able to distinguish between faults that occur in the secure state and those that occur in the non-secure state, and take appropriate action based on the context of the fault. By implementing a context-aware HardFault handler, it is possible to effectively diagnose and recover from faults in a system that implements both secure and non-secure states.
In conclusion, the ambiguity in the EXC_RETURN value when handling HardFaults in the non-secure state can be resolved by examining the CONTROL_NS.SPSEL bit and the stacked registers. By combining this information, it is possible to determine the exact context in which the fault occurred, allowing for more effective debugging and fault recovery. Additionally, implementing context-aware HardFault handlers that can handle faults in both the secure and non-secure states is essential for ensuring the reliability and robustness of the system.
