实时操作系统排障时怎样保留有效证据

嵌入式排障最令人抓狂的情况，莫过于设备在现场跑了三五天突然死机，连上 JTAG 调试器重启后现场却荡然无存。没有标准 Linux 那样丰富的日志文件系统，也没有高带宽网络能实时上报 Trace 数据。当 ARM Cortex-M 单片机在 FreeRTOS 或 RT-Thread 运行中触发 HardFault，或者出现死锁时，怎样在极受限的 SRAM/Flash 资源下留下一份能指认罪魁祸首的“现场证据”？

1. 现场噩梦：看懂 HardFault 崩溃现场

嵌入式设备崩溃时，系统默认的 HardFault_Handler 往往是一个无限死循环 while(1)。这种处理方式除了让看门狗复位设备之外，抹掉了所有关键线索。

系统在触发异常时，ARM 内核会自动将 R0-R3、R12、LR、PC、xPSR 压入当前的堆栈（MSP 或 PSP）。如果不主动保存这些寄存器并写入 Flash 的日志保留区（Log Crash Sector），死机复位后就什么都不剩了。

2. 证据收集：HardFault 现场上下文自动导出

我们需要重写 HardFault_Handler。通过一段极简的裸机汇编代码判别异常发生时使用的是主堆栈（MSP）还是进程堆栈（PSP），并将堆栈指针作为参数传递给 C 语言保存函数。

下面的 C/ASM 混合代码实现了现场寄存器与 SCB（System Control Block）故障状态寄存器的抓取与 Flash 写入逻辑：

#include <stdint.h>
#include <stdio.h>

typedef struct {
    uint32_t r0;
    uint32_t r1;
    uint32_t r2;
    uint32_t r3;
    uint32_t r12;
    uint32_t lr;  // Link Register
    uint32_t pc;  // Program Counter (崩溃代码地址!)
    uint32_t psr;
} CrashStackFrame_t;

// SCB 寄存器地址定义
#define SCB_CFSR  (*(volatile uint32_t*)0xE000ED28) // Configurable Fault Status Register
#define SCB_HFSR  (*(volatile uint32_t*)0xE000ED2C) // HardFault Status Register
#define SCB_BFAR  (*(volatile uint32_t*)0xE000ED38) // BusFault Address Register

// C 语言崩溃记录处理器
void Crash_Save_Context_C(uint32_t *hardfault_args) {
    CrashStackFrame_t *frame = (CrashStackFrame_t*)hardfault_args;
    
    uint32_t cfsr = SCB_CFSR;
    uint32_t hfsr = SCB_HFSR;
    uint32_t bfar = SCB_BFAR;

    // 假设内嵌轻量级 Flash 写入接口 (仅示例)
    printf("\n==== HARDFAULT DETECTED ====\n");
    printf("PC  (Crash Addr) = 0x%08X\n", frame->pc);
    printf("LR  (Return Addr)= 0x%08X\n", frame->lr);
    printf("R0  = 0x%08X, R1 = 0x%08X\n", frame->r0, frame->r1);
    printf("CFSR= 0x%08X, BFAR = 0x%08X\n", cfsr, bfar);

    if (cfsr & (1 << 7)) { // BFARVALID
        printf("[BUS FAULT] Invalid access at memory address: 0x%08X\n", bfar);
    }

    // 在这里将数据安全擦写保存至 Flash 的固定 Log 保留区
    // Flash_Write_Crash_Sector(frame, cfsr, bfar);

    for (volatile int i = 0; i < 10000000; i++); // 延迟后重启
}

// 汇编入口：提取堆栈指针并转交 C 处理
__attribute__((naked)) void HardFault_Handler(void) {
    __asm volatile (
        "tst lr, #4\n"          // 检查 LR 第 2 位，判断压栈来源
        "ite eq\n"
        "mrseq r0, msp\n"        // 0: 使用 MSP (Main Stack)
        "mrsne r0, psp\n"        // 1: 使用 PSP (Process Stack)
        "b Crash_Save_Context_C\n"
    );
}

当代码因为解引用一个已被释放的 NULL 指针触发 BusFault 时，上面的代码能在设备重启前准确捕抓到崩溃瞬间的 PC 地址和 BFAR 内存地址。

3. 证据还原：GDB addr2line 快速定位罪魁祸首

设备复位后，系统启动脚本检测到 Flash 保留区存在未擦除的 Crash Log，通过串口将其打印出来：

==== HARDFAULT DETECTED ====
PC  (Crash Addr) = 0x0800412C
LR  (Return Addr)= 0x08005A10
CFSR= 0x00000082, BFAR = 0x00000004
[BUS FAULT] Invalid access at memory address: 0x00000004

拿到了崩溃时的 PC 地址 0x0800412C 后，在开发机上使用 arm-none-eabi-addr2line 结合符号文件进行定位：

$ arm-none-eabi-addr2line -e build/rtos_demo.elf -f -C 0x0800412C
Process_Sensor_Data
/Users/dev/workspace/rtos_demo/Core/Src/sensor_proc.c:142

终端清晰地指出了具体函数名与源文件行号。打开 sensor_proc.c 第 142 行：

141: sensor_packet_t *pkt = Get_Queue_Packet();
142: uint16_t status = pkt->header.status; // pkt 为 NULL，解引用 offset 0x04 触发 BusFault!

原来是没有校验 pkt 是否为空指针就直接读取其成员，导致了硬件总线 Fault！

4. 动态 Trace：环形 RTT/SEGGER 缓冲区日志

除了静态的崩溃上下文，任务死锁或优先级反转这类问题不会触发 HardFault。我们需要引入 Segger RTT 或轻量级 Circular Ring Buffer 记录系统最近 100 个 RTOS 任务切换事件。

使用 Bash 脚本解析来自 SEGGER SystemView 抓取的二进制 Event Stream 轨迹：

$ systemview_cli_parser -f systemview_trace.bin | tail -n 15
[TIMESTAMP: 1204125 us] ISR Enter: SysTick (ID: 15)
[TIMESTAMP: 1204130 us] Task Switch Out: Task_GUI (Priority: 1)
[TIMESTAMP: 1204132 us] Task Switch In: Task_Telemetry (Priority: 3)
[TIMESTAMP: 1204500 us] Task Blocked: Task_Telemetry (Waiting Semaphore 0x20001040)
[TIMESTAMP: 1204505 us] Task Switch In: Task_Idle (Priority: 0)

通过这个轨迹记录，可以清晰发现 Task_Telemetry 任务在 1204500 us 时因为等待信号量 0x20001040 被阻塞，后续导致整个处理链条中断。

5. 总结

在 RTOS 嵌入式开发中留下有效的排障证据，关键在于建立三层防护：

1. 汇编级 HardFault 捕抓：提取真实的 PC、LR 寄存器与 SCB Fault 状态，写入 Flash 防止重启后数据丢失。
2. 符号表还原工具链：熟练运用 arm-none-eabi-addr2line 和 gdb 将内存地址还原为真实源码行。
3. 轻量 Trace 环形缓存：利用 RTT/SystemView 记录崩溃前极短时间内的任务切换与信号量事件。