HardFault_Handler：嵌入式系统崩溃现场的“黑匣子”与“急救室”
你有没有过这样的经历？
凌晨两点，调试板上的 LED 突然停闪，串口日志戛然而止，J-Link 显示“Target not halted”，而你的代码里连个printf都还没来得及输出——系统无声挂掉，像被按下了静音键。
这不是玄学，是 Cortex-M 在用最沉默的方式告诉你：它已经扛不住了。
而那个唯一还醒着、能说话、能记录、能求救的模块，就是HardFault_Handler。
它不是一段可有可无的空函数，也不是链接脚本里被自动填充的占位符。它是芯片在彻底失控前，留给开发者最后的、也是最真实的一份事故报告单。
它为什么总在最坏的时候出现？
先抛开手册里那些“不可屏蔽异常”“优先级 –1”的术语。我们从一个更贴近工程现实的视角看：
当你写p = (int*)0xdeadbeef; *p = 1;，
当你递归调用没设终止条件，栈一路冲破0x20000000往下扎，
当你在中断里调用了malloc()却忘了关调度器，
当你把一个未初始化的函数指针当真函数去call……
Cortex-M 不会弹窗提示“段错误”，也不会打印堆栈跟踪。它只做三件事：
✅立刻暂停当前指令流；
✅把此刻 CPU 的关键状态（R0–R3、LR、PC、xPSR 等）原封不动压进栈里；
✅跳转到向量表第 11 项（偏移 0x2C）——也就是HardFault_Handler的入口地址。
这个过程不经过任何软件判断，没有 if 判断，没有回调注册，纯硬件触发。所以它永远在线，永不缺席——哪怕你的main()还没开始跑，哪怕SysTick中断还没使能，只要硬件检测到无法归类的致命错误，它就登场。
这也意味着：如果你的HardFault_Handler没响应，那问题比你想的更底层——可能是向量表放错了位置、栈指针初始值非法、甚至 Flash 启动配置出错。
真正有用的HardFault_Handler，长什么样？
别再复制粘贴网上那段“只点亮 LED 然后死循环”的示例了。那不是诊断，是掩埋证据。
一个值得放进量产固件的HardFault_Handler，必须满足三个硬性要求：
🔹寄存器状态不丢失（哪怕栈已损坏，也要抢在二次崩溃前读完关键寄存器）；
🔹故障信息可提取（不只是“崩了”，而是“在哪崩的、为什么崩的、访问了哪个非法地址”）；
🔹行为可控可扩展（调试时能停住、生产时能上报、安全场景中能锁死）。
下面这段代码，已在多个 STM32F4/F7/H7 项目中经受住高温老化、EMC 干扰和长期无人值守考验：
// hardfault_ha
