Forced Hardfault (INVPC) on Cortex-M33 in Non-Secure Mode with FreeRTOS

ARM Cortex-M33 INVPC Hardfault During Context Restoration in FreeRTOS

The ARM Cortex-M33 processor, with its TrustZone security extension, introduces a layer of complexity when running real-time operating systems like FreeRTOS, especially in non-secure mode. A common issue that arises is the occurrence of a forced hardfault with the INVPC (Invalid PC Load) exception during the restoration of the context in FreeRTOS. This typically happens at the end of the vRestoreContextOfFirstTask function when attempting to jump to the EXC_RETURN value of 0xFFFFFFBC. The INVPC hardfault indicates that the processor is trying to load an invalid program counter (PC) value, which is often tied to incorrect stack handling or improper configuration of the security state.

The Cortex-M33’s dual-stack mechanism (secure and non-secure stacks) and the TrustZone security model require careful management of the stack pointers and exception return behavior. When FreeRTOS is configured to run in non-secure mode, the EXC_RETURN value must correctly reflect the security state and stack selection. Misconfiguration of these elements can lead to the INVPC hardfault, as the processor attempts to restore the context from an incorrect or invalid stack.

Misconfigured EXC_RETURN Value and Stack Selection

The INVPC hardfault on the Cortex-M33 during FreeRTOS context restoration is often caused by an incorrect EXC_RETURN value or improper stack selection. The EXC_RETURN value is a 32-bit field that determines the behavior of the exception return, including the security state and the stack to be used. For non-secure FreeRTOS implementations, the EXC_RETURN value must be set to 0xFFFFFFBC, which indicates a return to non-secure state using the non-secure main stack pointer (MSP).

However, the issue can arise if the stack being used for context restoration is not aligned with the security state specified by EXC_RETURN. For example, if the processor attempts to restore the context from the secure stack while EXC_RETURN is configured for non-secure state, the INVPC hardfault will occur. Additionally, the Cortex-M33’s default behavior after reset is to operate in secure mode, which can lead to mismatches in stack handling if FreeRTOS is configured to run in non-secure mode without proper initialization.

Another potential cause is the omission of the configRUN_FREERTOS_SECURE_ONLY configuration in the FreeRTOSConfig.h file. This macro determines whether FreeRTOS runs exclusively in secure mode. If this macro is not defined or set to 0, FreeRTOS may attempt to operate in non-secure mode without the necessary adjustments to the stack pointers and EXC_RETURN value, leading to the INVPC hardfault.

Correcting EXC_RETURN and Stack Configuration for Non-Secure FreeRTOS

To resolve the INVPC hardfault issue on the Cortex-M33 when running FreeRTOS in non-secure mode, the following steps should be taken:

1. Verify and Set the Correct EXC_RETURN Value: Ensure that the EXC_RETURN value used during context restoration is 0xFFFFFFBC. This value specifies a return to non-secure state using the non-secure MSP. The vRestoreContextOfFirstTask function should be reviewed to confirm that this value is correctly set before the exception return instruction is executed.

2. Configure FreeRTOS for Non-Secure Mode: In the FreeRTOSConfig.h file, define the configRUN_FREERTOS_SECURE_ONLY macro and set it to 0. This ensures that FreeRTOS operates in non-secure mode and properly initializes the non-secure stack pointers. If this macro is not defined, FreeRTOS may default to secure mode, leading to stack mismatches and the INVPC hardfault.

3. Initialize the Non-Secure Stack Pointer: Before starting the FreeRTOS scheduler, ensure that the non-secure stack pointer (MSP_NS) is correctly initialized. This can be done by writing to the MSP_NS register in the secure firmware. The initialization code should set the MSP_NS to the base address of the non-secure stack region.

4. Implement Stack Boundary Checks: Add runtime checks to verify that the stack pointers (both secure and non-secure) remain within their allocated memory regions. This can help catch stack overflows or misconfigurations that might lead to the INVPC hardfault.

5. Debugging and Tracing: Use a debugger to trace the execution flow and inspect the stack pointers and EXC_RETURN value at the point of the hardfault. This can provide insights into whether the stack or EXC_RETURN value is incorrect. Additionally, enable the Cortex-M33’s fault handlers to capture detailed information about the hardfault, including the stacked registers and fault status registers.

6. Review TrustZone Configuration: Ensure that the TrustZone security state is correctly configured for all peripherals and memory regions used by FreeRTOS. Misconfigured security attributes can lead to unexpected behavior during context switching and exception handling.

By following these steps, the INVPC hardfault issue on the Cortex-M33 when running FreeRTOS in non-secure mode can be effectively diagnosed and resolved. Proper configuration of the EXC_RETURN value, stack pointers, and TrustZone settings is critical to ensuring reliable operation of the real-time operating system on this advanced ARM processor.