——为什么调试器会在运行中改我的Flash程序？

调试单片机时，很多人都有这样的疑问：

明明我在调试前刷进去的固件是好的，为什么加了一个断点之后，调试器居然去改了 Flash？
如果我拔掉调试器，这个固件还能正常跑吗？

今天我们就来完整讲一讲**软件断点（Software Breakpoint）**的原理，以及它和 MCU Flash 之间的关系。

---

1. 什么是断点？

调试器要让程序在某一行停下来，有两种方法：

断点类型	原理	数量限制	速度	是否改写代码
硬件断点	利用 MCU 内部的 FPB（Flash Patch and Breakpoint） 单元，在指令地址匹配时自动中断	一般 4~6 个	极快	否
软件断点	直接把目标指令改成一条特殊的“陷阱指令”（如 BKPT）	理论无限（可写内存）	RAM 中快，Flash 中慢	是

 

所以，ST-Link / J-Link / DAPLink 这些调试器本质上都一样，只是硬件断点数量受 MCU 限制，而软件断点理论上可以很多，但需要改写代码。

---

2. 软件断点的工作原理

以 ARM Cortex-M 为例，软件断点的流程是这样的：

1. 下断点
   调试器接收到“在地址 0x08001234 停下来”的指令。

2. 备份原指令
   从 MCU 读出该地址的机器码（2 字节或 4 字节），保存到调试器内存。

3. 写入陷阱指令
   将该位置改成 BKPT #imm（机器码通常是 0xBE00）。

4. 运行时触发异常
   CPU 执行到 BKPT → 进入 Debug 模式 → 调试器接管。

5. 恢复原指令
   当你“移除断点”或“单步执行”时，调试器把原机器码写回去。

关键点：

• 如果断点地址在 RAM 中，直接写就行，很快，也不会磨损。

• 如果断点地址在 Flash 中，就必须擦除整页 → 改一条指令 → 回写整页，这会稍微慢一些，还会增加 Flash 擦写次数。

---

3. 为什么调试器会改 Flash？

因为软件断点就是修改原程序的一个过程。

• 硬件断点不改代码，但数量有限。

• 软件断点数量无限，但需要替换原来的指令为 BKPT。

• 在 Flash 中替换指令 → 必须擦写 Flash。

这也解释了两个现象：

1. 加 Flash 断点有延迟：那是擦写 Flash 的时间（几十到几百微秒）。

2. 断点太多可能会磨损 Flash：虽然调试时次数不多，但确实有写入动作。

---

4. 调试结束后的风险

大多数调试器在结束调试时，会自动恢复原指令。
但在以下情况可能会残留 BKPT：

• IDE / 调试器崩溃；

• 直接拔掉 USB / 断电；

• 固件编译时手动写了 __BKPT()，且 Release 版没屏蔽。

如果 BKPT 留在 Flash 里，MCU 在无调试器连接的情况下运行到这里：

• 会触发 HardFault 或 Debug Monitor Exception；

• 如果程序没有异常处理，就会直接死机。

---

5. 如何避免死机

1. 发布版本不用软件断点
   确保 Release 固件是干净的，不带调试指令。

2. 异常处理里跳过 BKPT
   在 HardFault Handler 中检查指令，如果是 BKPT，就跳过它：

   void HardFault_Handler(void) {uint32_t *pc = (uint32_t *)__get_MSP();if (*(uint16_t *)(*pc) == 0xBE00) { // BKPT*pc += 2; // 跳过断点指令return;}while (1); // 其他错误
   }
   

    

3. 调试结束前移除断点
   养成好习惯，不要让调试器崩溃时处于有断点的状态。

---

6. 总结

• 硬件断点：靠 MCU 内部比较器实现，不改代码，速度快但数量有限。

• 软件断点：通过改指令（RAM 直接写，Flash 要擦写）实现，数量无限但会改程序。

• 调试结束时如果 BKPT 没被恢复，独立运行可能直接死机。

• 最安全的做法是：发布固件前移除所有软件断点，并做好异常处理。