ARM Cortex-M4 Hard Fault During Nested Interrupt Handling and Mode Transition

ARM Cortex-M4 Hard Fault Due to Invalid EXC_RETURN and Stack Frame Manipulation

The core issue revolves around a Hard Fault occurring on an ARM Cortex-M4 microcontroller when attempting to transition from Handler mode to Thread mode during nested interrupt handling. The fault is triggered by an invalid Program Counter (PC) load caused by an incorrect EXC_RETURN value or an improperly constructed stack frame. The specific fault reported in the System Control Block (SCB) Configuration Fault Status Register (CFSR) is 0x40000, indicating an "Invalid PC load usage fault." This fault arises when the processor attempts to load an invalid EXC_RETURN value into the PC, which can occur due to an improperly configured stack frame or incorrect context switching logic.

The code in question manipulates the stack frame directly to force a transition from Handler mode to Thread mode. This is done to handle a critical power supply voltage drop scenario, where the system must quickly switch to a low-power state powered by a backup battery. The transition logic works correctly for single interrupts (where the RETTOBASE bit in the SCB->ICSR register is set to 1) but fails during nested interrupts (where RETTOBASE is 0). The failure manifests as a Hard Fault, indicating a fundamental issue with the stack frame manipulation or the EXC_RETURN value used during the mode transition.

The primary challenge lies in ensuring that the stack frame and EXC_RETURN value are correctly configured for both single and nested interrupt scenarios. Specifically, the Program Status Register (PSR) in the stack frame must contain the correct exception number of the preempted interrupt, and the EXC_RETURN value must reflect the correct return behavior (e.g., returning to Thread mode using the Main Stack Pointer (MSP) or returning to Handler mode).

Incorrect EXC_RETURN Value and Stack Frame Configuration During Nested Interrupts

The root cause of the Hard Fault can be attributed to two main issues: an incorrect EXC_RETURN value and an improperly configured stack frame. These issues are exacerbated during nested interrupts, where the processor’s state and stack usage are more complex.

Incorrect EXC_RETURN Value

The EXC_RETURN value is a special code used by the ARM Cortex-M processor to determine the behavior of the exception return mechanism. It specifies whether to return to Thread mode or Handler mode and which stack pointer (MSP or PSP) to use. In the provided code, the EXC_RETURN value is hardcoded to 0xFFFFFFF9, which indicates a return to Thread mode using the MSP. However, this value is only valid for single interrupts. During nested interrupts, the EXC_RETURN value should be 0xFFFFFFF1, indicating a return to Handler mode using the MSP. Using the wrong EXC_RETURN value during nested interrupts results in an invalid PC load, triggering the Hard Fault.

Improper Stack Frame Configuration

The stack frame for an exception return must include specific registers, including R0-R3, R12, LR, PC, and PSR. The PSR must contain the correct exception number of the preempted interrupt to ensure proper context restoration. In the provided code, the PSR is hardcoded to 0x21000000, which does not reflect the actual exception number. This incorrect PSR value can lead to improper context restoration, especially during nested interrupts where multiple exceptions are active.

Additionally, the code attempts to manipulate both the MSP and PSP, which is unnecessary and potentially harmful. The PSP is typically used in Thread mode with an operating system, while the MSP is used in Handler mode. Mixing these stack pointers without a clear understanding of their roles can lead to stack corruption and unpredictable behavior.

Lack of Exception Number Handling

The code does not correctly handle the exception number of the preempted interrupt, which is required for proper stack frame configuration. The exception number must be included in the PSR of the stack frame to ensure that the processor can correctly restore the context. The current implementation reads active interrupts from the NVIC->IABR register, but this approach is inefficient and does not provide the necessary priority information to determine the correct exception number.

Implementing Correct EXC_RETURN Handling and Stack Frame Management

To resolve the Hard Fault issue and ensure reliable transitions from Handler mode to Thread mode, the following steps must be taken:

Step 1: Use the Correct EXC_RETURN Value

The EXC_RETURN value must be dynamically determined based on whether the processor is handling a single or nested interrupt. This can be achieved by checking the RETTOBASE bit in the SCB->ICSR register. If RETTOBASE is 1, the EXC_RETURN value should be 0xFFFFFFF9 (return to Thread mode using MSP). If RETTOBASE is 0, the EXC_RETURN value should be 0xFFFFFFF1 (return to Handler mode using MSP).

uint32_t get_exc_return_value() {
    if (SCB->ICSR & SCB_ICSR_RETTOBASE_Msk) {
        return 0xFFFFFFF9; // Single interrupt, return to Thread mode using MSP
    } else {
        return 0xFFFFFFF1; // Nested interrupt, return to Handler mode using MSP
    }
}

Step 2: Configure the Stack Frame Correctly

The stack frame must be configured with the correct exception number in the PSR. This can be achieved by reading the active exception number from the NVIC->IABR register and encoding it into the PSR. The PSR should also include the necessary flags for exception handling, such as the Thumb state bit.

uint32_t get_psr_value() {
    uint32_t active_exception = __CLZ(__RBIT(NVIC->IABR[0])); // Find the highest priority active exception
    return (0x21000000 | (active_exception << 24)); // Encode exception number into PSR
}

Step 3: Update the Stack Frame Manipulation Code

The stack frame manipulation code must be updated to use the correct EXC_RETURN and PSR values. Additionally, the code should only manipulate the MSP, as the PSP is not needed for this use case.

static void fn_getRidOfIRQ_goTo(void* goTo) {
    if (goTo != NULL) {
        RidOfIRQ_callback = goTo;
    }

    process_frame = (hw_stack_frame_t *)((uint32_t)&_estack - sizeof(hw_stack_frame_t));

    if (isInsideISR() == true_t) {
        process_frame->r0 = (uint32_t)NULL;
        process_frame->r1 = 0U;
        process_frame->r2 = 0U;
        process_frame->r3 = 0U;
        process_frame->r12 = 0U;
        process_frame->lr = (uint32_t)fn_getRidOfIRQ_goTo;
        process_frame->pc = (uint32_t)fn_getRidOfIRQ_goTo;
        process_frame->psr = get_psr_value(); // Use dynamically generated PSR value

        asm volatile ("MSR msp, %0\n\t" : : "r" (process_frame)); // Only manipulate MSP
        __asm volatile (
            " mov r0, #0 \n"
            " msr basepri, r0 \n"
            " mov lr, %0 \n" // Use dynamically generated EXC_RETURN value
            " isb \n"
            " bx lr \n"
            : : "r" (get_exc_return_value())
        );
    } else {
        asm volatile ("MSR msp, %0\n\t" : : "r" (process_frame)); // Only manipulate MSP
        RidOfIRQ_callback();
        while(1);
    }
}

Step 4: Validate the Solution

After implementing the above changes, the code should be thoroughly tested in both single and nested interrupt scenarios to ensure that the Hard Fault no longer occurs. The System Control Block (SCB) registers, including CFSR, HFSR, and BFAR, should be monitored to confirm that no faults are triggered during the mode transition.

By following these steps, the issue of Hard Faults during nested interrupt handling and mode transition can be resolved, ensuring reliable operation of the system in critical power supply scenarios.