HardFault发生时，CPU通过SCB->CFSR、HFSR、DFSR、AFSR寄存器记录错误类型，并依据模式（Thread/Handler）和VECTACTIVE确定有效SP地址，再从SP出发按固定偏移提取lr进行栈回溯，需严格匹配异常帧结构与地址有效性校验。
HardFault发生时，CPU到底留了哪些线索
ARM Cortex-M的HardFault异常触发后，只要没被破坏，SCB->CFSR、SCB->HFSR、SCB->DFSR 和 SCB->AFSR 这四个寄存器会直接告诉你错误类型（总线错误、内存管理违规、非法指令等）。更关键的是：如果Fault occurred in Thread mode且使用主栈（MSP），那当前的 __current_sp 就是故障发生瞬间的栈顶地址；如果是Handler mode或使用进程栈（PSP），得先从SCB->ICSR查VECTACTIVE再判断用哪个SP。漏掉这个分支，栈回溯直接从错的地址开始解，结果全不可信。
从SP地址开始还原调用栈的三步硬编码法
ARM Cortex-M（Thumb-2）函数返回地址总是保存在栈帧底部的lr（即r14）位置，而每个栈帧顶部通常有push {r4-r7, lr}或类似保存。所以手写回溯的核心逻辑就是：从当前sp出发，按固定偏移读取lr值，再根据该lr反推上一级函数的入口——但必须过滤掉无效地址：
-
lr值末位为1表示Thumb状态，合法地址应满足(lr & 0x1) == 1且lr >= 0x08000000（典型Flash起始）且lr （按你实际代码区调整） - 若
lr指向某函数末尾（如pop {r4-r7, pc}之后的地址），需手动减2跳回pop指令位置，再向上找最近的push——这步不能靠猜，得查你编译器生成的.map文件确认函数边界 - 遇到
lr == 0xfffffffd（EXC_RETURN值）说明已回溯到异常入口，停止；遇到lr == 0或未对齐地址（lr & 0x3非0）立即终止
为什么不能直接用__builtin_return_address或libbacktrace
这些工具依赖GCC的frame pointer（-fno-omit-frame-pointer）或DWARF调试信息，在裸机Cortex-M工程里几乎不存在：启动文件没开FP，链接脚本不带--gdb，.elf里也没有.debug_frame段。即使你加了-g，libbacktrace仍会尝试调用malloc和open()读文件——HardFault里这两个函数根本不可用。唯一可行路径是纯汇编+静态解析：scb_cfsr_read()读寄存器 → get_active_sp()判MSP/PSP → unwind_stack_from_sp(uint32_t sp)循环读栈，每步只用__LDREXW和位运算。
实战中第一个必须验证的细节：栈对齐与中断嵌套污染
Cortex-M要求栈指针16字节对齐（SP % 16 == 0），但HardFault可能发生在任意指令中间，此时SP可能未对齐。直接按4字节步进读栈会踩到中间数据。正确做法是先用sp = sp & ~0x3向下对齐，再检查*(uint32_t*)(sp + 0x10)是否看起来像一个合理的lr（末位为1、落在代码段内）。另外，如果HardFault由NMI或SysTick嵌套触发，SCB->ICSR里的VECTPENDING可能非零，此时当前SP其实是被压入的异常帧，真实用户栈在sp + 0x20（带浮点扩展则+0x40）——这个偏移量必须和你的startup_*.s里PendSV_Handler的保存逻辑严格一致，差1字节就全错。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
