——为什么调试器会在运行中改我的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 为例，软件断点的流程是这样的：

下断点
调试器接收到“在地址 0x08001234 停下来”的指令。
备份原指令
从 MCU 读出该地址的机器码（2 字节或 4 字节），保存到调试器内存。
写入陷阱指令
将该位置改成 BKPT #imm（机器码通常是 0xBE00）。
运行时触发异常
CPU 执行到 BKPT → 进入 Debug 模式 → 调试器接管。
恢复原指令
当你“移除断点”或“单步执行”时，调试器把原机器码写回去。

关键点：

如果断点地址在 RAM 中，直接写就行，很快，也不会磨损。
如果断点地址在 Flash 中，就必须擦除整页 → 改一条指令 → 回写整页，这会稍微慢一些，还会增加 Flash 擦写次数。

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

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

硬件断点不改代码，但数量有限。
软件断点数量无限，但需要替换原来的指令为 BKPT。
在 Flash 中替换指令 → 必须擦写 Flash。

这也解释了两个现象：

加 Flash 断点有延迟：那是擦写 Flash 的时间（几十到几百微秒）。
断点太多可能会磨损 Flash：虽然调试时次数不多，但确实有写入动作。

4. 调试结束后的风险

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

IDE / 调试器崩溃；
直接拔掉 USB / 断电；
固件编译时手动写了 __BKPT()，且 Release 版没屏蔽。

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

会触发 HardFault 或 Debug Monitor Exception；
如果程序没有异常处理，就会直接死机。

5. 如何避免死机

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

异常处理里跳过 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); // 其他错误
}