Finding Crashes and Faults

Faults are exceptions (unit 5, lesson 3). On entry, before the handler’s first instruction, the core pushes the basic frame of eight words onto the stack in use: r0, r1, r2, r3, r12, LR, the return address and xPSR, with r0 at the lowest address. Cores with an FPU (Cortex-M4F, M7, M33) push a 26-word extended frame instead when floating-point state is active, with the same eight words first. It then loads LR with an EXC_RETURN value that says how to return, and therefore where the frame is:

Armv8-M cores add further bits for their security states; the principle is the same.

↑ This step uses the figure at the top of the page.

The stacked return address is the key: for a precise fault it is the address of the instruction that faulted. Look it up in the disassembly or with addr2line -e app.elf 0x08000c52. The stacked LR tells you where that function was called from, and a backtrace that unwinds through the exception frame (lesson 3) usually shows the rest.

If the stack pointer was not 8-byte aligned when the exception arrived, the core inserts four bytes of padding and records it in bit 9 of the stacked xPSR (always on Armv6-M; on Armv7-M when CCR.STKALIGN is set, the default on recent cores). For a basic frame, the pre-exception SP is the frame base plus 32, plus 4 if that bit is set:

$$SP_{\text{before}} = SP_{\text{frame}} + 32 + 4 \cdot \text{xPSR}[9]$$

An infinite loop in the handler is fine under a debugger but useless in the field. A better handler finds the frame and records it:

__attribute__((used, noreturn)) void fault_record(uint32_t *frame);

void HardFault_Handler(void) __attribute__((naked));
void HardFault_Handler(void) {
    __asm volatile(
        "movs r0, #4          \n"   /* EXC_RETURN bit 2: 0 = MSP, 1 = PSP */
        "mov  r1, lr          \n"
        "tst  r0, r1          \n"
        "beq  1f              \n"
        "mrs  r0, psp         \n"
        "bl   fault_record    \n"   /* bl reaches ±16 MiB; b only ±2 KiB on Armv6-M */
        "1: mrs r0, msp       \n"
        "bl   fault_record    \n");
}
void fault_record(uint32_t *frame) {
    /* frame[6] is the stacked PC, frame[5] the stacked LR */
    crash_log.pc = frame[6];
    crash_log.lr = frame[5];
    crash_log.cfsr = SCB->CFSR;   /* Armv7-M only; omit on Armv6-M */
    for (;;) {}                   /* or reset, after saving crash_log */
}

The assembly uses only instructions available on Armv6-M, so it works on a Cortex-M0+ too; bl overwrites LR, which no longer matters because fault_record never returns. Keep crash_log in a RAM section that start-up code does not zero (.noinit, unit 5, lesson 4), and after a watchdog or software reset the next boot can report where the last crash happened.

A debugger can also stop at the moment of the fault rather than in the handler: the DEMCR vector-catch bits (for example VC_HARDERR) halt the core as the exception is taken.

A Cortex-M4 lands in HardFault. The handler recorded HFSR = 0x40000000 and CFSR = 0x00020000, stacked PC = 0x0800_1A30, stacked LR = 0x0800_0B77.

1. HFSR bit 30 (FORCED): the UsageFault handler is not enabled, so the fault escalated.
2. CFSR bit 17 (INVSTATE): the core tried to execute with the Thumb bit clear.
3. The stacked PC, 0x0800_1A30, is even and is the start of a function: something branched to it with bit 0 = 0.
4. The stacked LR, 0x0800_0B77, points into the caller. The code there calls through a function pointer that was assembled by hand as (void (*)(void))0x08001A30, without bit 0. Taking the function’s address (&handler) instead lets the linker set the bit.