——为什么调试器会在运行中改我的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); // 其他错误 }调试结束前移除断点
养成好习惯，不要让调试器崩溃时处于有断点的状态。
6. 总结
硬件断点：靠 MCU 内部比较器实现，不改代码，速度快但数量有限。
软件断点：通过改指令（RAM 直接写，Flash 要擦写）实现，数量无限但会改程序。
调试结束时如果 BKPT 没被恢复，独立运行可能直接死机。
最安全的做法是：发布固件前移除所有软件断点，并做好异常处理。