Cortex-M7 Frame Pointer Behavior and HardFault Stack Unwinding

Cortex-M7 Frame Pointer Setup and Stack Dependency in Function Prologue

The Cortex-M7 microcontroller, with its superscalar 6-stage pipeline, introduces unique considerations for stack management and frame pointer usage, especially when debugging HardFaults. In the provided code, the function prologue for I2cHW::endTransmission() demonstrates a sequence of operations that manipulate the stack pointer (SP) and frame pointer (R7). The prologue consists of three key instructions:

1. Push {r4, r5, r7, lr}: This instruction saves the contents of registers R4, R5, R7, and the link register (LR) onto the stack. The stack pointer (SP) is decremented by 32 bytes (4 registers × 8 bytes each).
2. Sub sp, #24: This instruction allocates an additional 24 bytes on the stack by further decrementing the stack pointer.
3. Add r7, sp, #16: This instruction sets the frame pointer (R7) to the current stack pointer (SP) plus 16 bytes.

The primary question here is why the frame pointer (R7) is set to SP + 16 instead of pointing to a more predictable location, such as the previously pushed R7 value or the original SP value before entering the function. This behavior is influenced by the Cortex-M7’s pipeline architecture and the need to maintain stack alignment and efficient access to local variables.

Cortex-M7 Pipeline and Stack Dependency

The Cortex-M7’s 6-stage pipeline can execute multiple instructions in parallel, but dependencies between instructions can cause stalls. In the prologue, the push instruction modifies the stack pointer (SP), and the subsequent sub instruction also modifies SP. The add instruction, which sets the frame pointer (R7), depends on the updated value of SP from the sub instruction. The pipeline must wait for the sub instruction to complete before executing the add instruction, introducing a potential stall.

The choice of SP + 16 for the frame pointer is deliberate. It allows the function to access local variables and saved registers efficiently. The 16-byte offset ensures that the frame pointer points to a location within the allocated stack space, providing a consistent reference point for accessing local variables and saved registers.

Challenges in HardFault Stack Unwinding and Call Stack Reconstruction

When a HardFault occurs, reconstructing the call stack is critical for diagnosing the root cause of the fault. The Cortex-M7’s stack frame structure and the use of the frame pointer (R7) play a significant role in this process. However, several challenges arise when attempting to unwind the stack:

1. Frame Pointer Usage: The frame pointer (R7) is not always used consistently across functions, especially when compiler optimizations are applied. In some cases, the frame pointer may be omitted entirely, making it difficult to reconstruct the stack frame.
2. Stack Alignment: The Cortex-M7 requires 8-byte stack alignment for efficient memory access. Misaligned stacks can complicate stack unwinding and lead to incorrect interpretations of the stack contents.
3. Interrupt Context: When a HardFault occurs, the processor saves the context (registers) onto the stack. This saved context must be carefully parsed to determine the state of the program at the time of the fault.

Techniques for Stack Unwinding

To address these challenges, developers can employ several techniques to reconstruct the call stack during a HardFault:

1. Link Register (LR) Analysis: The link register (LR) contains the return address for the function that was executing when the fault occurred. By examining the LR value, developers can identify the function where the fault originated.
2. Stack Pointer (SP) Traversal: The stack pointer (SP) can be used to traverse the stack and locate saved return addresses. Each function call typically pushes the return address onto the stack, allowing developers to reconstruct the call chain.
3. Frame Pointer (R7) Usage: If the frame pointer (R7) is used consistently, it can serve as a reference point for locating saved registers and local variables. This can simplify the process of reconstructing the stack frame.

Example: HardFault Handler Implementation

The provided code includes a HardFault handler that attempts to reconstruct the call stack. The handler extracts the stack pointer (SP) and examines the saved context to determine the state of the program at the time of the fault. The following key steps are performed:

1. Extract Stack Pointer: The handler retrieves the stack pointer (SP) from the saved context.
2. Parse Saved Registers: The handler parses the saved registers, including the program counter (PC) and link register (LR), to identify the fault location.
3. Reconstruct Call Stack: The handler traverses the stack to locate saved return addresses and reconstruct the call stack.

The handler also includes diagnostic output to log the fault context, including the values of key registers and fault status registers (e.g., CFSR, HFSR). This information is critical for diagnosing the root cause of the fault.

Best Practices for HardFault Debugging and Stack Unwinding

To ensure reliable HardFault debugging and stack unwinding, developers should adhere to the following best practices:

1. Consistent Frame Pointer Usage: Ensure that the frame pointer (R7) is used consistently across functions. This can be achieved by compiling with the -fno-omit-frame-pointer flag.
2. Stack Alignment: Maintain 8-byte stack alignment to ensure efficient memory access and simplify stack unwinding.
3. Minimal Fault Handler Code: Keep the HardFault handler code minimal and avoid complex operations, such as sprintf, which can introduce additional risks.
4. Diagnostic Output: Include diagnostic output in the HardFault handler to log the fault context and aid in debugging.
5. Static Analysis: Use static analysis tools to identify potential stack issues, such as stack overflows or misaligned stacks.

Example: Optimized HardFault Handler

The following example demonstrates an optimized HardFault handler that avoids complex operations and focuses on extracting and logging the fault context:

void HardFault_Handler_c(int *pStackDump) {
    volatile unsigned long _MSP = __get_MSP(); // Get Main Stack Pointer
    volatile StackContents_t *stackContents = (volatile StackContents_t *) pStackDump;

    // Extract fault status registers
    volatile unsigned long _CFSR = (*((volatile unsigned long *)(0xE000ED28))); // Configurable Fault Status Register
    volatile unsigned long _HFSR = (*((volatile unsigned long *)(0xE000ED2C))); // Hard Fault Status Register
    volatile unsigned long _DFSR = (*((volatile unsigned long *)(0xE000ED30))); // Debug Fault Status Register
    volatile unsigned long _AFSR = (*((volatile unsigned long *)(0xE000ED3C))); // Auxiliary Fault Status Register
    volatile unsigned long _MMAR = (*((volatile unsigned long *)(0xE000ED34))); // MemManage Fault Address Register
    volatile unsigned long _BFAR = (*((volatile unsigned long *)(0xE000ED38))); // Bus Fault Address Register

    // Log fault context
    logFaultContext(_MSP, _CFSR, _HFSR, _DFSR, _AFSR, _MMAR, _BFAR, stackContents);

    // Reconstruct call stack
    reconstructCallStack(_MSP);
}

void logFaultContext(unsigned long _MSP, unsigned long _CFSR, unsigned long _HFSR, unsigned long _DFSR, unsigned long _AFSR, unsigned long _MMAR, unsigned long _BFAR, StackContents_t *stackContents) {
    // Log fault context to a buffer or external interface
    // Example: UART, logging framework, etc.
}

void reconstructCallStack(unsigned long _MSP) {
    // Traverse the stack to locate saved return addresses
    // Reconstruct the call stack and log the results
}

Conclusion

Understanding the Cortex-M7’s frame pointer behavior and stack management is critical for effective HardFault debugging and stack unwinding. By adhering to best practices and employing optimized techniques, developers can reliably diagnose and resolve complex issues in their embedded systems. The provided examples and insights serve as a foundation for building robust and maintainable HardFault handlers, ensuring that developers can quickly identify and address the root causes of faults in their applications.