4. 异常捕获：硬件异常（HardFault、MemManage等）、软件异常捕获、异常向量表重定向
异常捕获这个话题，说实话，是嵌入式开发中最让人头疼的部分之一。我做了这么多年HAL层开发，见过太多同事在异常面前束手无策——程序跑飞了，看门狗复位了，但就是不知道问题出在哪。今天我们就来彻底搞懂它。
4.1 硬件异常家族：你可能会遇到的几种“死法”
Cortex-M内核定义了一套完整的异常体系。我个人习惯把它们分成两类：一类是“必死无疑”的，比如HardFault；另一类是“还有救”的，比如可配置的MemManage、BusFault等。
| 异常类型 | 优先级 | 触发场景 | 我见过的典型案例 |
|---|---|---|---|
| HardFault | -1（最高） | 其他故障无法处理时 | 访问了未对齐的地址 |
| MemManage | 可配置 | MPU违规访问 | 任务栈溢出踩到了内核区 |
| BusFault | 可配置 | 总线事务错误 | 外设时钟没开就去读寄存器 |
| UsageFault | 可配置 | 指令/数据使用错误 | 除零操作、未对齐的LDM指令 |
嗯，这里要注意：HardFault是“兜底”的。如果其他故障没使能，它们都会上访成HardFault。所以很多新手只看到HardFault，却不知道真正的原因是什么。
4.2 硬件异常捕获：从现场“挖”出根因
硬件异常发生时，CPU会自动压栈一些寄存器。这些寄存器里藏着“案发现场”的关键线索。我一般会做三件事：
- 读取故障状态寄存器——判断是哪种异常
- 读取故障地址寄存器——找到出错的地址
- 解析堆栈帧——还原出问题时的PC指针和LR
举个例子，我曾经遇到一个MemManage异常，死活找不到原因。后来打印出MMFAR（MemManage Fault Address Register），发现地址是0x2000_0000附近——那是任务栈的边界。说白了，就是栈溢出了。
// 一个实用的HardFault钩子函数
void HardFault_Handler(void) {
// 读取故障状态
uint32_t cfsr = SCB->CFSR;
uint32_t hfsr = SCB->HFSR;
uint32_t mmfar = SCB->MMFAR;
uint32_t bfar = SCB->BFAR;
// 解析堆栈帧（关键！）
uint32_t *stack = (uint32_t*)__get_MSP();
uint32_t pc = stack[6]; // 压栈顺序：R0-R3,R12,LR,PC,xPSR
uint32_t lr = stack[5];
// 打印到调试串口
printf("HardFault! PC=0x%08X, LR=0x%08X\n", pc, lr);
printf("CFSR=0x%08X, MMFAR=0x%08X\n", cfsr, mmfar);
// 死循环等待调试器介入
while(1);
}4.3 软件异常捕获：主动“制造”异常的艺术
硬件异常是被动的，但有时候我们需要主动捕获软件层面的错误。比如参数校验失败、断言失败、内存越界等。我个人习惯在HAL层里统一注册一个软件异常处理入口。
你想想看，如果每个模块都自己处理错误，那调试起来得多乱？我建议的做法是：
- 定义一个统一的错误码枚举
- 所有模块通过同一个接口上报异常
- 异常处理中心统一记录和响应
// 软件异常捕获的统一接口
typedef enum {
ERR_NONE = 0,
ERR_PARAM_INVALID, // 参数无效
ERR_TIMEOUT, // 超时
ERR_MEMORY_OVERFLOW, // 内存溢出
ERR_NULL_POINTER, // 空指针
ERR_ASSERT_FAILED // 断言失败
} ErrorCode_t;
void HAL_ErrorCapture(ErrorCode_t err, const char *file, int line) {
// 记录到错误日志缓冲区
error_log[error_count].code = err;
error_log[error_count].file = file;
error_log[error_count].line = line;
error_count++;
// 如果是致命错误，触发断点或复位
if (err == ERR_ASSERT_FAILED || err == ERR_NULL_POINTER) {
__disable_irq();
while(1); // 等待调试器
}
}
// 使用宏简化调用
#define HAL_ASSERT(cond) \
do { \
if (!(cond)) { \
HAL_ErrorCapture(ERR_ASSERT_FAILED, __FILE__, __LINE__); \
} \
} while(0)4.4 异常向量表重定向：把控制权拿回来
默认情况下，异常向量表放在Flash的起始地址。但有时候我们需要在运行时动态修改它——比如做Bootloader、OTA升级、或者像我在某个项目中做的，把异常处理重定向到RAM里，方便调试时修改。
说白了，就是告诉CPU：“别去Flash找异常处理函数了，来RAM里找我新写的。”
// 异常向量表重定向到RAM
#define VECTOR_TABLE_RAM_BASE 0x20000000 // RAM起始地址
void VectorTable_Redirect(void) {
// 1. 在RAM中分配空间（需对齐到256字节）
// 2. 复制Flash中的向量表到RAM
memcpy((void*)VECTOR_TABLE_RAM_BASE,
(void*)SCB->VTOR,
sizeof(VectorTable_t));
// 3. 修改VTOR寄存器指向RAM
SCB->VTOR = VECTOR_TABLE_RAM_BASE;
// 4. 现在可以修改RAM中的向量表了
// 比如：把HardFault_Handler换成我们自己的
VectorTable_t *vt = (VectorTable_t*)VECTOR_TABLE_RAM_BASE;
vt->HardFault = (uint32_t)&MyCustomHardFaultHandler;
}4.5 知识体系总览
下面这张图是我自己总结的异常捕获知识体系。你可以把它当作一个检查清单——遇到异常时，按这个流程走一遍，基本都能定位到问题。
这张图其实就讲了三件事：异常从哪来、怎么捕获、捕获后怎么定位。我个人觉得，只要把这三个环节打通了，大部分异常问题都能在半小时内解决。