摘要：在嵌入式现场，设备死机通常意味着巨大的维护成本。当 STM32 进入 HardFault_Handler 时，标准的 while(1) 处理方式掩盖了所有真相。本文将深入 Cortex-M 架构的异常堆栈机制，通过一段混合汇编代码，提取案发现场的寄存器（R0-R3, PC, LR），并结合 GNU 工具链（addr2line），实现精准的代码行级定位。

---

一、 案发现场：为什么 Call Stack 会消失？

当发生非法内存访问（空指针、数组越界）或执行非法指令时，CPU 会立即跳转到 HardFault_Handler。

此时，如果你点击 IDE 的 Call Stack，往往只能看到 HardFault_Handler 这一行。为什么？ 因为从崩溃点跳转到异常中断时，硬件自动进行了一次压栈 (Stack Push) 操作，改变了当前的栈环境。IDE 有时无法跨越这个“异常边界”去回溯之前的调用链。

我们需要做的，就是手工把这些被硬件压入栈的数据挖出来。

---

二、 理论基础：硬件入栈顺序

当 Cortex-M (M3/M4/M7) 进入中断时，它会自动把 8 个寄存器压入当前使用的堆栈（MSP 或 PSP）。顺序如下：

1. xPSR : 程序状态寄存器

2. PC (Program Counter) : **关键！**这是死机时，CPU 正在执行的那条指令地址。

3. LR (Link Register) : **关键！**这是死机函数的返回地址（即谁调用了死机函数）。

4. R12

5. R3

6. R2

7. R1

8. R0

只要我们能拿到这个栈顶指针，就能顺藤摸瓜找到 PC 和 LR 的值。

---

三、 第一步：用汇编接管 HardFault

标准的 HardFault_Handler 通常是 C 语言写的，但为了提取栈指针（SP），我们需要用汇编 (Assembly) 作为入口。

因为在进入 Handler 的瞬间，我们需要判断 CPU 刚才用的是 MSP（主堆栈）还是 PSP（进程堆栈，RTOS 任务通常用这个）。这个信息存储在 LR 寄存器的 Bit 2 中。

HardFault_Handler.c (Keil/GCC 通用逻辑)

// 定义一个结构体来映射栈上的数据，方便 C 语言访问
typedef struct {
    uint32_t r0;
    uint32_t r1;
    uint32_t r2;
    uint32_t r3;
    uint32_t r12;
    uint32_t lr;
    uint32_t pc;  // <--- 凶手就在这里
    uint32_t xpsr;
} ExceptionStackFrame;

// 真正的 C 语言处理函数
void HardFault_Handler_C(ExceptionStackFrame *frame) {
    // 这里可以使用 printf 或者我们在之前文章写的 CrashLog 写入 Flash
    printf("\r\n[Hard Fault]\r\n");
    printf("R0   = 0x%08X\r\n", frame->r0);
    printf("R1   = 0x%08X\r\n", frame->r1);
    printf("R2   = 0x%08X\r\n", frame->r2);
    printf("R3   = 0x%08X\r\n", frame->r3);
    printf("R12  = 0x%08X\r\n", frame->r12);
    printf("LR   = 0x%08X\r\n", frame->lr);
    printf("PC   = 0x%08X (Crash Address)\r\n", frame->pc);
    printf("xPSR = 0x%08X\r\n", frame->xpsr);

    // 死机卡住
    while (1);
}

// 汇编入口 (Naked 函数，不生成标准的函数序言/结语)
#if defined(__CC_ARM) || defined(__ARMCC_VERSION) 
// Keil AC5/AC6 写法
__attribute__((naked)) void HardFault_Handler(void) {
    __asm(
        "TST lr, #4 \n"        // 测试 LR 的 bit 2
        "ITE EQ \n"            // If-Then-Else 指令
        "MRSEQ r0, MSP \n"     // 如果是 0，说明之前用的是 MSP，把 MSP 存入 R0
        "MRSNE r0, PSP \n"     // 如果是 1，说明之前用的是 PSP，把 PSP 存入 R0
        "B HardFault_Handler_C \n" // 跳转到 C 函数，R0 作为参数传入
    );
}
#elif defined(__GNUC__)
// GCC / STM32CubeIDE 写法
void HardFault_Handler(void) __attribute__((naked));
void HardFault_Handler(void) {
    __asm volatile(
        "tst lr, #4 \n"
        "ite eq \n"
        "mrs_eq r0, msp \n"
        "mrs_ne r0, psp \n"
        "b HardFault_Handler_C \n"
    );
}
#endif

四、 第二步：尸检分析 (addr2line)

假设你的串口打印出了如下信息：

[Hard Fault]
...
LR   = 0x08001A4B
PC   = 0x08000284 (Crash Address)
...

0x08000284 就是崩溃的地址。怎么知道它是哪一行代码？

我们需要用到 GNU 工具链中的神器：addr2line。 (即使你用 Keil，只要安装了 GCC 工具链也可以用这个工具，或者查看 Keil 的 .map 文件)

1. 使用命令行工具

打开终端，找到你的编译器目录（例如 arm-none-eabi-addr2line），执行命令：

# -e 指定你的 .elf 文件 (CubeIDE/GCC生成) 或 .axf 文件 (Keil生成)
# -f 显示函数名
# -C (大写) 解析 C++ 的 Name Mangling (非常重要！)
arm-none-eabi-addr2line -e your_project.elf -f -C 0x08000284

2. 输出结果

SensorTask::ProcessData()
E:/Work/Project/Core/Src/Sensor.cpp:45

真相大白！ 崩溃发生在 Sensor.cpp 的第 45 行，函数是 SensorTask::ProcessData。 此时你去检查代码，可能第 45 行写着 ptr[i] = 0; 而 ptr 是个野指针。

---

五、 进阶：如何分析 C++ 的虚函数崩溃？

在 C++ 中，如果调用了一个被销毁对象的虚函数，或者未初始化的 std::function，PC 指针往往会指向一个极其离谱的地址（比如 0x00000000 或 0xFFFFFFFE）。

这时候 PC 值本身已经没用了，因为它跳到了荒野。 我们需要看 LR (Link Register)。

• 场景：PC = 0x00000000 (非法跳转)

• 分析：说明是有人执行了 BLX 或 BX 跳转到了 0。

• 查看 LR：假设 LR = 0x08001A4B。

• 执行 addr2line：查 0x08001A4B。

• 结果：EventBus::Publish，行号 120。

• 推断：在 EventBus::Publish 的第 120 行，你调用了一个回调函数，但这个回调函数是空的，或者指向了 NULL。

---

六、 总结

通过这套 汇编跳板 + C 语言打印 + addr2line 分析 的组合拳，你拥有了嵌入式开发中的“黑匣子分析”能力。

1. 汇编入口：区分 MSP/PSP，获取栈顶指针。

2. C 结构体：解析栈帧，提取 PC 和 LR。

3. addr2line：将由 PC/LR 的十六进制地址翻译成 文件名:行号。

建议：结合之前的《Flash 崩溃日志》文章，将这个 ExceptionStackFrame 写入 Flash。下次设备从现场寄回来，你只需要读出 Flash 里的 0x0800xxxx，敲一下命令行，Bug 就原形毕露了。

这就是硬核嵌入式工程师的 Debug 方式：不靠猜，只看寄存器。