干嵌入式这行，谁没被 HardFault 折磨过？程序跑着跑着不动了，调试器一暂停，光标停在启动文件那个死循环里，看着红堂堂的“HardFault_Handler”就知道又踩坑了。HardFault 本质是 ARM Cortex-M 内核的异常机制在兜底，当总线错误、用法错误、存储器管理错误一路升级到无法收拾时，处理器会强制跳进这个最高等级的故障入口。今天这篇就围绕 STM32 的 HardFault 触发来源做一次完整的 ARM 异常故障复盘，从异常家族、触发链路、现场还原、定位手段一直到防御设计，一次性把这条线讲透。适合被 HardFault 折磨的新手，也适合正在升级 Bootloader、准备上 RTOS 的开发者。
1. HardFault 是怎么冒出来的：ARM 异常家族与触发总览
1.1 Cortex-M 异常优先级：谁把错误升格成了 HardFault
Cortex-M 内核里有一套完整的异常向量表，复位、NMI、HardFault、MemManage、BusFault、UsageFault，此外还有一堆外设中断。很多人拿到 HAL 库后直接写中断回调，却很少关注这些异常之间的优先级关系，结果一旦出错，只能在 HardFault_Handler 里一脸懵。
先看一张关键优先级表：
| 异常名称 | 优先级 | 是否可配置 | 默认使能状态 |
|---|---|---|---|
| Reset | -3 | 不可配置 | 始终可用 |
| NMI | -2 | 不可配置 | 始终可用 |
| HardFault | -1 | 不可配置 | 始终可用 |
| MemManage | 可配置 | 可单独使能 | 默认关闭 |
| BusFault | 可配置 | 可单独使能 | 默认关闭 |
| UsageFault | 可配置 | 可单独使能 | 默认关闭 |
这里的核心要点在于：MemManage、BusFault、UsageFault 这三个可配置故障，默认是关着的。工程里如果没有主动通过SCB->SHCSR去打开它们，那么当代码触发了存储器访问违规、总线错误或者非法指令时，内核不会跳进对应的 Handler，而是“升级”成 HardFault，直接一脚踢进 HardFault_Handler。
这也是很多人觉得 HardFault 不好定位的第一个原因：信息被吞掉了。你看到的只有最高层的故障入口，而具体是什么类型的错误，需要自己去读状态寄存器才能知道。
1.2 HardFault 的三条产生路径
HardFault 本身不是单一错误，它是故障的“收容所”，大致有三条路径会走到这里。
第一条路径是配置型故障升级。MemManage、BusFault、UsageFault 任何一个被触发，但对应的异常没有使能，或者该异常的优先级不低于当前正在执行的上下文，就会被升级成 HardFault。这是最常见的一条路。
第二条路径是异常压栈/出栈失败。当处理器进入异常、需要把 xPSR、PC、LR、R12、R3-R0 压入栈时，如果栈指针已经跑到无效地址，压栈动作本身就失败，内核会再次触发 HardFault。这种情况常见于栈耗尽。
第三条路径是取向量表失败。比如系统在复位时读取复位向量地址，或者异常入口的向量地址超出了合法范围，也会进入 HardFault。
判断当前 HardFault 是不是“升级”来的，有一个非常直接的标记位：HFSR 寄存器（0xE000ED2C）的第31位 FORCED。如果这一位是 1，说明故障是由其他异常上升而来；如果这一位是 0，说明是内核直接触发，比如压栈失败或取向量失败。
2. 常见的 HardFault 触发来源：六类问题逐个拆解
2.1 非法存储器访问：空指针、野指针与越界
STM32 的存储器映射是固定的几个大区，Flash 在 0x08000000，SRAM 在 0x20000000，外设寄存器在 0x40000000。如果你的代码访问了这些区域之外的地址，或者访问了未被映射的“空洞”，总线就会报告错误，最终一路升级成 HardFault。
实际开发中最典型的操作是直接解引用一个非法地址：
*(uint32_t *)0x50000000 = 0x01; // 这个地址在STM32F1上不存在这类代码看似极端，但真实场景里很常见。比如 DMA 的缓冲区地址算错、结构体指针强转后偏移错误、外设寄存器基地址被宏定义写错，都会产生非法地址访问。
数组越界更是重灾区。C 语言不会检查数组边界，你定义一个uint8_t buf[8]，然后循环写 20 个字节，写出去的内容会悄悄覆盖相邻变量。如果越界量足够大，会把函数的栈帧、返回地址甚至调用者的局部变量全部打乱，程序不会立刻崩溃，而是在某个后续操作中突然进入 HardFault，现场极其迷惑。
这里要特别提醒位带操作。很多人用位带方式操作 GPIO 或者外设寄存器，位带别名区的地址换算必须严格对应 SRAM 或外设的 1MB 映射区间。一旦位带地址算错，访问到的地址可能落在未映射区域，直接总线错误进 HardFault。
2.2 栈溢出：从主栈 MSP 到任务栈 PSP
栈溢出是 HardFault 的头号嫌疑犯，但也是最容易被忽略的。Cortex-M 有两个栈指针：MSP 主栈指针和 PSP 线程栈指针。裸机环境下，主程序和中断都用 MSP；RTOS 环境下，任务运行用 PSP，中断依然用 MSP。
主栈溢出最常见的场景是中断服务函数里放大数组：
void TIM2_IRQHandler(void) { uint8_t buf[1024]; // 中断里突然吃掉 1KB 栈 memset(buf, 0, sizeof(buf)); // 处理数据 }如果系统主栈只分配了 4KB，原本主程序已经用掉 3KB，中断一来压栈 + 局部数组瞬间穿透栈底，SP 指向非法地址。此时进入中断需要压栈，压栈动作本身失败，内核直接触发 HardFault。
RTOS 场景下任务栈溢出更隐蔽。每个任务有自己的栈，当任务函数里局部变量过大，或者函数调用层级过深，任务栈就被写穿。FreeRTOS 里有个uxTaskGetStackHighWaterMark()接口，能查询任务栈的历史最低水位，但这个接口必须在任务还活着且没有彻底破坏时才能正确返回。栈溢出如果已经破坏了任务控制块，往往整个系统行为都会变得不可预测。
2.3 未定义指令与 PC 跑飞
PC 跑飞是另一类高频触发来源。Cortex-M 内核只支持 Thumb 指令集，PC 的最低一位必须为 1，表示 Thumb 状态。如果跳转地址的最低位是 0，内核会认为状态错误，触发 UsageFault 后再升级为 HardFault。
最常见的场景是函数指针调用错误：
void (*func)(void) = (void (*)(void))0x08002000; func();如果 0x08002000 这个地址最低位是 0，调用时就会出问题。正确写法应该是保留最低位为 1，比如跳转到 0x08002001。很多人在 Bootloader 跳转 App 时忽略了这个细节，用手敲了一个偶地址，跳过去就死。
还有一种情况是栈内容被破坏后，函数的返回地址被篡改，程序执行流跳到了数据区或者未初始化 Flash 区。这时候反汇编窗口看到的 PC 值往往是奇奇怪怪的地址，比如 0x0800xxxx 指向的是一段常量池，或者 0x2000xxxx 指向堆区。
2.4 非对齐访问与特殊指令
关于非对齐访问，有一个常见的认识误区：Cortex-M3/M4 默认是允许普通非对齐访问的。比如你用*(uint32_t *)(address + 1) = 0x12345678;这种写法，默认情况下不会报错，只是性能变差。但如果工程里设置了SCB->CCR的 UNALIGN_TRP 位，那么任何非对齐访问都会触发 UsageFault。
真正会导致 HardFault 的，是那些强制要求对齐的多字节指令，比如 LDM、STM、LDRD、STRD 等。如果一个结构体被强转成奇地址，然后代码用 32 位指针去读，编译器可能生成 LDR 指令，这种指令本身允许非对齐；但如果用 LDRD 之类的双字加载，就会触发总线错误。
Cortex-M0/M0+ 的情况更严苛，任何非对齐访问都会直接触发 HardFault。所以跨内核移植代码时，缓冲区指针对齐问题必须重点检查。
2.5 外设误操作与配置错误
外设误操作导致的 HardFault 经常被忽视，因为它发生在看起来完全正常的驱动代码里。
一个非常典型的例子是：没有使能外设时钟，就去操作外设寄存器。STM32 的 RCC 控制着所有外设时钟，如果对应的位没有置 1，访问该外设寄存器时可能产生总线错误，最终升级成 HardFault。很多新手在初始化外设前忘了调__HAL_RCC_GPIOA_CLK_ENABLE()，结果第一句写 GPIOA 的 MODER 就死掉。
DMA 配置错误也是常见来源。外设地址或者内存地址写错，传输长度计算错误，导致 DMA 控制器去读写非法地址，这种情况下总线错误往往在不精确的时刻才上报，定位起来更麻烦。
还有一个反直觉的例子：在中断服务函数里执行了不安全的操作。比如在中断里调用了 malloc，或者调用了某些非中断安全的库函数。这些函数内部如果访问了不合适的地址，中断上下文瞬间崩掉，而中断里的故障定位比主循环里难得多。
2.6 RTOS 调度与临界区：看似没事实际已坏
用上 FreeRTOS 之后，HardFault 的出现频率往往会上升，原因是调度机制把栈和上下文切分得更细了。
先说一个最常见的配置问题：PendSV 和 SysTick 的优先级。FreeRTOS 要求这两个异常优先级设置为最低，并且两者相同。如果 SysTick 优先级设得比某些中断高，或者 PendSV 配置错误，系统在切换上下文时可能出现异常嵌套，导致栈和寄存器现场错乱，进 HardFault。
再比如在中断服务函数里调用非中断安全的 API，比如vTaskDelay()而不是vTaskDelayFromISR()，这种调用可能引起临界区状态错乱。最直接的结果就是系统跑一段时间后突然 HardFault，而且完全没有规律。
任务函数结束时没有删除任务，也是新手容易踩的坑。如果一个任务函数 return 了，但又没有调用vTaskDelete(NULL)，那么从该任务返回的代码路径是未知的，执行流可能跑到任意地方。
3. 案发现场还原：寄存器状态与异常机制详解
3.1 异常压栈机制：那 8 个寄存器就是案发现场
定位 HardFault 最重要的不是猜测，而是把现场还原出来。Cortex-M 硬件在进入异常时，会自动把 xPSR、PC、LR、R12、R3、R2、R1、R0 这 8 个值压入当前栈，组成一个 32 字节的异常帧。
压栈完成后，SP 指向异常帧的最低地址。也就是说：
| 偏移 | 内容 |
|---|---|
| sp[0] | xPSR |
| sp[1] | PC |
| sp[2] | LR |
| sp[3] | R12 |
| sp[4] | R3 |
| sp[5] | R2 |
| sp[6] | R1 |
| sp[7] | R0 |
这里面的 PC 就是故障发生时的执行位置，它是最有价值的线索。LR 则是上层调用者的返回地址，用来还原调用链。R0-R3 是形参和临时变量，有时能提供额外的上下文信息。
关键问题是：故障现场的栈是 MSP 还是 PSP？这要看进入 HardFault_Handler 时 LR 寄存器的值。Cortex-M 使用 EXC_RETURN 编码值来表示异常返回模式：
- LR = 0xFFFFFFF9：线程模式 + MSP
- LR = 0xFFFFFFF1：线程模式 + PSP
- LR = 0xFFFFFFFD：处理器模式 + MSP
FreeRTOS 任务运行在 PSP，如果 HardFault 打断的是任务，LR 通常是 0xFFFFFFF1；如果打断的是中断或裸机主程序，LR 通常是 0xFFFFFFF9。
3.2 三个状态寄存器怎么读：CFSR/HFSR/DFSR
光拿到 PC 还不够，还需要知道故障的类型。这几个寄存器是定位的核心：
- CFSR（0xE000ED28）：可配置故障状态寄存器，实际上由 MMFSR、BFSR、UFSR 三个子寄存器组成
- HFSR（0xE000ED2C）：硬故障状态寄存器
- BFAR（0xE000ED38）：总线故障地址寄存器
- MMFAR（0xE000ED34）：存储器管理故障地址寄存器
CFSR 的位含义很丰富。BFSR 里的 PRECISERR 表示精确总线错误，此时 BFAR 有效，能直接告诉你出错地址；IMPRECISERR 表示不精确总线错误，BFAR 无效，这种错误通常跟写缓冲、乱序执行有关。UFSR 里的 UNDEFINSTR 表示未定义指令，INVSTATE 表示指令状态错误，DIVBYZERO 表示除零（前提是 CCR 里的 DIV_0_TRP 已使能）。
实操中我习惯先读 HFSR 看 FORCED 是否为 1，再去读 CFSR 拆解具体故障。读这两个寄存器不需要额外使能，直接访问地址即可。
3.3 BFAR/MMFAR：精确地址与近似地址
当 CFSR 中 PRECISERR 置位时，BFAR 会保存触发总线错误的精确地址。这是最理想的情况，直接看 BFAR 就知道哪块内存出了问题。
但现实往往没那么友好。Cortex-M7 和带写缓冲的内核上，写操作触发错误时，处理器可能已经执行了好几条指令，错误上报被延后。此时 PRECISERR 不置位，BFAR 无效，你只能通过栈里的 PC 值反推附近代码，检查哪条写操作访问了非法地址。
如果 BFAR 的值是 0x08000000 附近，大概率是 Flash 访问问题；如果是 0x20000000 附近，多半是 SRAM 访问越界；如果是 0x40000000 附近，就要查外设寄存器配置。
3.4 一个可粘贴的 HardFault 现场提取方案
为了不让 HardFault_Handler 变成黑洞，我习惯在工程里挂一个现场提取函数。这个方法的核心是在异常入口处判断栈指针，然后把异常帧保存下来，供后续打印或调试器查看。
下面这段代码适用于 AC6 和 GCC，核心思路是裸函数里根据 LR 判断 MSP/PSP：
void HardFault_Handler(void) __attribute__((naked)); void HardFault_Handler(void) { __asm volatile( "TST LR, #0x04 \n" "ITE EQ \n" "MRSEQ R0, MSP \n" "MRSNE R0, PSP \n" "B HardFault_Collect \n" ); } 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; uint32_t cfsr; uint32_t hfsr; uint32_t bfar; uint32_t mmar; uint32_t msp; uint32_t psp; } HardFaultContext; volatile HardFaultContext g_fault; void HardFault_Collect(uint32_t *sp) { g_fault.r0 = sp[7]; g_fault.r1 = sp[6]; g_fault.r2 = sp[5]; g_fault.r3 = sp[4]; g_fault.r12 = sp[3]; g_fault.lr = sp[2]; g_fault.pc = sp[1]; g_fault.xpsr = sp[0]; g_fault.cfsr = *((volatile uint32_t *)0xE000ED28); g_fault.hfsr = *((volatile uint32_t *)0xE000ED2C); g_fault.bfar = *((volatile uint32_t *)0xE000ED38); g_fault.mmar = *((volatile uint32_t *)0xE000ED34); g_fault.msp = (uint32_t)__get_MSP(); g_fault.psp = (uint32_t)__get_PSP(); while (1); }注意，这段代码使用的是编译器内置的__get_MSP()/__get_PSP()，需要包含对应的 CMSIS 头文件。裸函数写法在不同编译器下细节略有差异，AC5 的__asm关键字和 AC6 的__attribute__((naked))不完全一样，移植时按编译器的实际情况调整。
有一个容易踩的细节：进入 HardFault_Handler 时，LR 指向 EXC_RETURN 值，而不是栈帧里的 LR。所以异常恢复必须要用异常帧里的 sp[2]，不是当前 LR 寄存器。
4. 实操定位说白了就是三板斧：调试器、串口与栈回溯
4.1 第一板斧：调试器直读，最快定位数组越界和指针问题
在开发阶段，调试器是最直接的手段。很多人一看程序停在 HardFault_Handler 就慌了，其实只要按顺序走一遍，多数问题都能当场看出眉目。
首先要做的，是把断点从 HardFault_Handler 的死循环 while 移到函数第一行，或者直接在进入 HardFault_Handler 的汇编第一条指令处暂停，否则现场可能被后面的优化破坏。
接下来按这个顺序操作：
- 打开 Registers 窗口，看当前 LR。根据 EXC_RETURN 判断之前使用的是 MSP 还是 PSP。
- 读 HFSR，确认 FORCED 位是否为 1。
- 读 CFSR，把置位的那些标志位记下来。这一步直接告诉你故障类型是总线错误、存储器管理错误还是用法错误。
- 根据 LR 判断结果，在内存窗口输入 MSP 或 PSP 的值。
- 内存窗口里依次找到异常帧：sp[0] 是 xPSR，sp[1] 是 PC，sp[2] 是 LR。
- 把 sp[1] 的 PC 值记下来，在反汇编窗口按地址跳转过去，看那条指令在做什么。
- 再看 sp[2] 的 LR，找到上层调用者，还原调用链。
这里有一个隐藏技巧：当 PC 指向的指令是 LDR、STR 等访存指令时，重点关注它访问的地址寄存器；如果是 BL、BX 等跳转指令，重点检查目标地址的合法性。在实际排查中，PC 附近那几条指令往往已经把问题写得明明白白。
4.2 第二板斧：串口打印与故障信息上云
调试器只能覆盖开发阶段，到了现场测试或者产线阶段，就得靠串口把故障信息带出来。
我通常会在 HardFault_Collect 里面加一个串口发送函数，把 g_fault 结构体的关键字段格式化后打出来。打印内容的核心字段包括：故障类型、PC、LR、SP、CFSR、HFSR、BFAR。如果用了 RTOS，还可以把任务列表里的当前任务名打印出来。
打印时要注意，HardFault 发生后系统已经处于不可靠状态，串口发送函数最好不要依赖中断，直接采用轮询方式发送。如果串口驱动本身使用 DMA，现场可能已经坏掉，DMA 反而帮倒忙。
更稳的做法是把故障记录到一段独立的内存区域，比如备份 SRAM 或者专门划分的 RAM 区域。重启后系统能读取这段记录并上报上位机，实现“故障转储”。这样即使复位了，信息也不丢。
4.3 第三板斧：开源栈回溯组件的接入与原理
串口打印只能看到当前 PC 和 LR，没法自动还原完整调用链。好在有开源栈回溯组件可以自动完成这件事，它的原理是：
- 根据 PC 值在符号表里查找函数名
- 用 LR 构建调用链的上层节点
- 扫描栈内存，寻找符合返回地址特征的值，逐步向上还原调用关系
- 在 RTOS 场景下，结合任务栈边界信息，判断当前故障属于哪个任务
接入这类组件有几个关键前提。第一，编译时必须保留符号信息，不能 strip 掉 map 文件或者符号表。第二，优化等级不要开太高，-O2 以上会把很多调用栈的 LR 优化掉，导致回溯链条断裂。第三，栈数据不能被破坏得太严重，如果栈溢出已经把返回地址全部抹掉，回溯组件也无能为力。
组件本身不复杂，但要做好多一层心理准备：它给出的是“最可能的调用链”，不是“绝对准确的调用链”。在栈被局部破坏时，回溯结果可能指向错误的函数。所以这种工具适合快速缩小范围，最终的定论还是要结合源代码审查。
4.4 第四板斧：FreeRTOS 任务的栈水位检测与钩子函数
FreeRTOS 场景下有一个专门检测任务栈溢出的钩子函数：
void vApplicationStackOverflowHook(TaskHandle_t pxTask, char *pcTaskName) { // 记录任务名和句柄 while (1); }这个钩子在栈溢出被检测到时触发，但它并不是万能的。它检测的触发条件是pxTopOfStack附近的已知标志被破坏，或者当前 PSP 已经超出了任务栈范围。如果溢出没有经过栈顶区域，比如任务内部的局部变量写穿但没有触及 TCB，钩子可能永远不触发。
更可靠的办法是定期调用uxTaskGetStackHighWaterMark()检查剩余栈空间，把历史上最小的水位记录下来。如果多个任务的水位都接近 100 字节以内，说明任务栈分配偏紧，需要加大。
还有个经验：任务栈底部的金丝雀检测最好自己补一层。FreeRTOS 在某些移植层会在栈底填充已知值，但没有标准化的检查接口。你可以在创建任务时手动把任务栈全部填充成 0xA5A5A5A5，然后周期性扫描，一旦发现这些值被改写，就说明栈曾经被压穿过。
for (int i = 0; i < task_stack_size / 4; i++) { if (task_stack[i] != 0xA5A5A5A5) { // 栈被压穿 } }这个方法的优点是简单粗暴，缺点是只能事后发现，不能精确定位是哪个函数压穿的。不过结合 PC 值和调用栈，通常也能拼出完整链条。
5. 排查实录与常见问题速查表
5.1 案例一：跑着跑着死在奇怪的 0x0800xxxx
某开发者的程序在主循环里跑一会儿就 HardFault，PC 指向一个 0x0800xxxx 地址，反汇编看到的却是常量区。CFSR 里 UFSR 的 INVERET? 未定义指令标志置位，HFSR 的 FORCED 为 1。
排查过程：通过异常帧里的 LR 找到上层调用函数，再阅读源码发现是某个局部数组越界，把函数栈里的返回地址写坏。函数正常执行到 return 时，CPU 从栈里弹出被篡改的 LR，跳到常量区，执行非法指令，触发 UsageFault 升级成 HardFault。
这个案例给的经验是：如果 PC 指向的不是函数代码，而是常量池或者数据区，优先怀疑栈里的返回地址被破坏。数组越界、memcpy 长度算错、结构体赋值越界都可能造成这种结果。
5.2 案例二：中断里的大数组，MSP 直接被压穿
另一个很实际的案例是某设备在外部事件触发时随机 HardFault，频率不高但一出现就死。CFSR 里 BFSR 的 STKERR 置位，HFSR 的 FORCED 置位，说明异常压栈时栈空间不足。
检查发现某个外设中断服务函数里定义了一块 2KB 的局部缓冲区，而系统主栈只有 4KB，运行过程中主程序本身占用已有 3KB，中断一进来压栈 + 大数组直接爆栈。
这个案例的教训很直接：中断服务函数里不要放大的局部数组。大块缓冲区要么用全局静态变量，要么用动态分配的独立内存，要么用 DMA 直接在内存和外设之间搬数据。中断函数的栈开销越少越好。
5.3 案例三：Bootloader 跳转 App 后立刻 HardFault
固件升级功能做了 Bootloader 和 App 分区的开发者，大概率踩过这个坑。Bootloader 跳转到 App 后，系统立刻 HardFault，连 App 的 main 都没进去。
最常见的两个原因：一是没有设置中断向量表偏移，二是跳转地址最低位处理错误。
正确跳转流程是：
#define APP_FLASH_BASE 0x08008000 uint32_t app_sp = *(volatile uint32_t *)APP_FLASH_BASE; uint32_t app_pc = *(volatile uint32_t *)(APP_FLASH_BASE + 4); SCB->VTOR = APP_FLASH_BASE; // 先把向量表搬过去 __set_MSP(app_sp); // 再设置主栈 ((void (*)(void))app_pc)(); // 最后跳转App 工程的链接脚本也要把 Flash 起始地址改成 0x08008000，向量表的位置要和 Bootloader 约定好。如果 SCB->VTOR 没有在 App 开头重新设置，SysTick 或者其他中断一触发，CPU 直接去 0x08000000 找中断向量，对应的处理函数地址已经不对了，自然进 HardFault。
5.4 案例四：FreeRTOS 任务一跑就 HardFault
一个跑 FreeRTOS 的小项目，创建两个任务后，其中一个任务一运行就卡死，HardFault_Handler 里看 PC 指向任务函数的中间位置，CFSR 置位的是 BUSFAULT。
通过寄存器和栈回溯发现，任务函数里分配了一个 400 字节的局部缓冲区，但任务栈分配只有 256 字节，函数进入后局部变量初始化就写穿了任务栈。修改方式有两种：要么把任务栈改到 1024 字节，要么把大缓冲区从局部变量改成静态变量或全局变量。
任务栈大小不能拍脑袋定，一般建议根据任务内所有嵌套函数调用的栈需求之和，再叠加中断嵌套的开销，留下至少 20% 余量。使用uxTaskGetStackHighWaterMark()实测是最稳妥的评估方式。
5.5 排查实录：从症状到方向的速查表
| 症状 | 大概率原因 | 建议定位手段 |
|---|---|---|
| PC 指向奇怪地址 / 常量区 | 栈返回地址被破坏 | 查异常帧 LR，回顾数组越界和 memcpy 长度 |
| CFSR 中 STKERR 置位 | 栈空间不足 | 检查 MSP/PSP 水位，查中断里的大数组 |
| BFAR = 0x40000000 附近 | 外设寄存器访问错误 | 检查外设时钟使能和寄存器地址 |
| BFAR = 0x20000000 附近 | SRAM 访问越界 | 查指针运算、数组下标、DMA 缓冲区 |
| UFSR 中 INVSTATE 置位 | 跳转到奇数地址/非法函数指针 | 检查函数指针最低位、Bootloader 跳转 |
| RTOS 任务一运行就死 | 任务栈过小 | 加大任务栈并查水位 |
| Bootloader 跳转后立刻死 | VTOR 未重设 | 检查向量表偏移和链接脚本 |
6. 从“救火”到“免疫”：防御性设计怎么做
6.1 编译期与运行期断言：让错误更早暴露
HardFault 之所以难定位，很多时候是因为问题在几百毫秒甚至几秒之前就已经埋下，只是到某个时刻才爆发。如果能在错误发生的第一时间把现场暴露出来，排查成本会骤降。
工程里建议把标准库的 assert_param 或者自定义断言机制打开。HAL 库和标准外设库都提供 assert_param 宏，默认是关闭的。把它打开后，接口参数非法时会在入口处报错，很多指针参数错误就能在源头被截住。
运行期断言更实用，比如对函数指针跳转前校验地址范围：
if ((addr & 1) == 0) { // 地址最低位为 0，不是合法的 Thumb 跳转目标 }这类检查看起来笨，但关键跳转路径上加上之后，能挡住一大类 Bootloader 跳转问题。
6.2 内存布局与栈设计：把风险区隔开
内存规划上有一个很有效的防御手段：给任务栈和关键数据区之间留一个“哨兵区”，在哨兵区里填充固定模式值，周期性扫描。
更激进的做法是开启 MPU。在 Cortex-M3/M4 上，MPU 可以给特定内存区间设置访问权限，比如把数组末尾后面的一小段区域配置成“禁止访问”，一旦代码越界写入，就会触发 MemManage 异常，进而进入 HardFault。虽然这看起来还是 HardFault，但至少错误是确定的，不会出现栈被悄悄写坏、延迟几百毫秒才爆炸的诡异场景。
栈大小的设计原则是宁大勿小。裸机下主栈建议至少 2KB，如果放了 RTOS，每个常规任务栈至少 512 字节起步，涉及大局部数组、浮点和 printf 的任务栈更大。创建设备表时顺手记录每个任务的水位，后续调优就有依据。
6.3 看门狗与故障转储：让现场保存下来
生产环境里，HardFault_Handler 里 while(1) 死等是最差的结果。系统死在那里，用户看不到任何提示，只能强制断电。更合理的策略是：HardFault 发生后，保存故障现场到备份寄存器或备份 SRAM，然后通过 IWDG 触发复位，重启后把故障信息上报。
用备份寄存器保存现场的开销很小，STM32 的备份寄存器可以保存几个 32 位数据，关键字段比如 PC、LR、CFSR 足够存下。备份寄存器在系统复位后不会被清零，下次启动时可以直接读取。
IWDG 的配合方式要注意：HardFault_Handler 里如果长时间停留，IWDG 会超时复位。想现场调试时可以先暂停 IWDG，或者直接把故障信息打完再喂狗，让系统保持可观察状态。这个细节容易被忽略，很多人把 IWDG 打开后，HardFault_Handler 里的调试逻辑还没执行完就被复位了。
6.4 我个人的几个实测习惯
最后分享几个我踩过不少坑之后沉淀下来的习惯。每次新建工程，第一件事就是在 HardFault_Handler 里挂上现场提取代码，哪怕暂时没有串口打印，也要保证故障帧能被调试器看到。其次是所有中断服务函数里禁止定义大数组、禁止调用 malloc，这是硬性规则，团队成员写代码时我都会查。
然后是 IWDG 和备份寄存器的组合，我在量产项目里必加。产品如果跑着跑着随机 HardFault，现场人员的反馈永远只有“死机”两个字。有了故障转储，拿到 PC 和 CFSR 就能把随机问题变成可控问题。
还有一个小技巧：在开发阶段，把三个可配置故障全部打开，并把它们的优先级配置成最低。这样发生问题时会优先进入 MemManage/BusFault/UsageFault 的独立 Handler，而不是直接升级到 HardFault。每个 Handler 里挂不同的调试断点，能立刻区分故障大类。
SCB->SHCSR |= SCB_SHCSR_MEMFAULTENA_Msk | SCB_SHCSR_BUSFAULTENA_Msk | SCB_SHCSR_USGFAULTENA_Msk;光靠被动救火是不够的。把故障定位的路径提前铺好，比事后折腾调试器省太多时间。HardFault 并不可怕，可怕的是现场被破坏之后完全无从下手。先把退路留好，剩下的问题，慢慢查总能查出来。
