单片机死机时无法主动执行代码，Backup Registers写入必须在HardFault等异常处理中争分夺秒完成：需用汇编获取压栈寄存器、关闭中断、使能备份域时钟、解除写保护后写入RTC_BKP0R~BKP4R，复位后立即读取解析。
单片机死机时无法主动执行代码，Backup Registers 写入必须在复位前完成
绝大多数 Cortex-M（如 STM32）或 8051 类单片机的 Backup Registers（BKP/RTC_BKPx）本身不支持“死机瞬间自动捕获寄存器”，它只是掉电后仍能保持的普通 RAM 区域。真正能写入的时机只有：程序仍在运行但已检测到即将崩溃（如 HardFault、MemManage 异常），或在异常处理函数中争分夺秒完成保存。一旦 CPU 真正锁死（如总线悬挂、时钟停振、非法指令卡死无异常向量响应），就再没有机会执行任何 C++ 代码——此时 BackupRegisters 不可能被写入。
所以实际可行路径只有一条：在异常服务例程（如 HardFault_Handler）中，用汇编或内联汇编快速读取 CPU 寄存器，并写入 RTC_BKP0R～RTC_BKP4R 等可用寄存器。
- 必须关闭中断（
__disable_irq()），避免嵌套异常干扰写入流程 - 不能调用任何可能触发内存访问（如 printf、malloc）、浮点运算或未初始化外设的函数
- STM32F4/F7/H7 需先使能备份域时钟：
RCC_APB1ENR |= RCC_APB1ENR_BKPEN（F4）或RCC_APB1ENR1 |= RCC_APB1ENR1_BKPEN（H7） - 写入前需解除备份寄存器写保护：
PWR_CR |= PWR_CR_DBP（并等待PWR_CSR & PWR_CSR_DBP置位）
如何在 HardFault_Handler 中安全获取 r0–r3、r12、lr、pc、psp/msp 和 xPSR
ARM Cortex-M 的异常进入会自动压栈部分寄存器（取决于使用 PSP 还是 MSP）。若你在 HardFault_Handler 中用 C 函数声明（如 void HardFault_Handler(void)），编译器会生成函数序言，覆盖原始 r0–r3；因此必须用汇编入口 + C 封装，或直接在汇编中完成寄存器提取和写入。
推荐做法：定义一个不带参数、不保存 caller-saved 寄存器的 C 函数，由汇编 Handler 调用，并通过 __attribute__((naked)) 禁止编译器插入 prologue/epilogue：
立即学习“C++免费学习笔记（深入）”；
extern "C" void HardFault_Capture(uint32_t *sp) __attribute__((naked));
void HardFault_Capture(uint32_t *sp) {
// sp 指向异常发生时压入的栈帧（8 个字：r0-r3, r12, lr, pc, xPSR）
// 注意：若使用 PSP，则需先读取 psp；若使用 MSP，则用 msp
uint32_t r0 = sp[0];
uint32_t r1 = sp[1];
uint32_t r2 = sp[2];
uint32_t r3 = sp[3];
uint32_t r12 = sp[4];
uint32_t lr = sp[5];
uint32_t pc = sp[6];
uint32_t psr = sp[7];
// 写入 Backup Register（以 STM32H7 为例，BKP0R ~ BKP4R 共 5 个 32 位寄存器）
RTC->BKP0R = r0;
RTC->BKP1R = r1;
RTC->BKP2R = r2;
RTC->BKP3R = r3;
RTC->BKP4R = pc; // 或组合存入 psr/pc/lr
// 死循环，防止返回后继续跑飞
while(1);
}
关键点：
- 不要依赖
__get_MSP()或__get_PSP()获取栈指针——它们返回的是当前 SP，而非异常进入时的 SP；正确方式是让汇编 Handler 把sp作为第一个参数传入 - STM32 的
RTC_BKPxR是 32 位寄存器，最多存 5 组数据；若需更多（如完整 16 个通用寄存器），需外扩 EEPROM 或利用 Flash 保留页（但写 Flash 有延时且寿命有限） - 某些芯片（如 GD32）备份寄存器地址映射不同，务必查对应参考手册中的
RTC_BKPxR偏移，而非硬编码0x50
复位后如何从 Backup Registers 读出并解析现场
系统上电或从待机/关机唤醒后，只要 VBAT 供电正常且备份域未被复位（即未触发 PWR_CR & PWR_CR_BRR），RTC_BKP0R～RTC_BKP4R 的值就保持不变。你可以在 main() 开头立即读取它们：
// 假设之前存了 r0/r1/r2/r3/pc
uint32_t saved_r0 = RTC->BKP0R;
uint32_t saved_r1 = RTC->BKP1R;
uint32_t saved_r2 = RTC->BKP2R;
uint32_t saved_r3 = RTC->BKP3R;
uint32_t saved_pc = RTC->BKP4R;
// 可打印或通过 UART 发送（注意：此时 UART 外设需已初始化）
printf("Crash PC: 0x%08X\n", saved_pc);
printf("R0-R3: %08X %08X %08X %08X\n", saved_r0, saved_r1, saved_r2, saved_r3);
// 清空备份寄存器（可选），避免下次复位误判
RTC->BKP0R = 0;
RTC->BKP1R = 0;
RTC->BKP2R = 0;
RTC->BKP3R = 0;
RTC->BKP4R = 0;
注意：
- 读取前无需再次使能 BKP 时钟或取消写保护（读操作不受 DBP 位影响）
- 若使用了低功耗模式（如 Standby），需确认 VBAT 是否连接并供电；否则备份寄存器内容将丢失
- 不要在
main()中过晚读取——比如等 RTOS 启动后再读，中间若有其他模块清空了 BKP，就再也找不回现场了
为什么不能用 C++ 异常机制捕获单片机死机
C++ try/catch 对硬件异常完全无效。它只能捕获由 throw 显式抛出的异常，而 HardFault、BusFault、UsageFault 等属于 ARM 架构级异常，由 NVIC 硬件直接跳转至对应 Handler 地址，绕过所有 C++ 运行时栈展开逻辑。试图在 main() 外层包一层 try，对死机毫无意义。
更隐蔽的坑：
- 某些调试器（如 ST-Link）在 HardFault 发生后会暂停 CPU 并显示 Fault Status Register，但此时若点击 “Run”，调试器可能自动清除 FAULTMASK/PRIMASK，导致系统继续跑飞甚至覆盖备份寄存器
- 使用
assert()或自定义断言宏时，若其内部调用了未初始化的串口或延时函数，反而会自己触发第二次 HardFault，覆盖第一次的现场 - Backup Register 容量极小（通常仅 5×32bit），不适合存堆栈 dump 或字符串；想看函数名？得靠离线 addr2line + map 文件，而不是往 BKP 里塞 symbol 名
真正可靠的崩溃现场记录，永远建立在“异常第一时间裸写寄存器+最小化上下文”之上，其余都是锦上添花。
