难度：★★
本文首发于我的嵌入式技术号「OneChan讲Soc嵌入式」，未经授权禁止转载。
你肯定有过这样的体验：Keil 或 IAR 里点一下“Start/Stop Debug Session”，程序烧录完毕，调试器窗口弹出来，黄色的箭头稳稳地停在 main 的第一行。
但如果你在调试器设置里勾选了“Run to main”，而在启动文件里手动设了一个断点在 Reset_Handler 的第一条指令上，你会发现：调试器也能停在那里，在 CPU 刚执行完硬件复位、还没来得及跑任何用户代码的时候。
问题来了：Reset_Handler 是 CPU 复位后执行的第一条用户指令。在这条指令之前，没有任何软件在跑——没有操作系统，没有调试代理，没有任何程序能为调试器“铺路”。
那调试器是怎么在程序的第一条指令执行之前，就让它停下来的？
答案是：调试器用了两种截然不同的断点机制。它们在表面上的效果完全一样——程序暂停在某个地址——但在底层，一个靠硬件比较器，一个靠篡改指令。理解这两种机制的区别，你就理解了调试器为什么在 Flash 和 RAM 中的行为完全不同。
一、停在 main 容易，停在 Reset_Handler 难
先说为什么停在 main 容易。
main 是一个普通的 C 函数。它的地址在 Flash 中，编译链接之后就确定了。调试器在启动时，解析 ELF 文件，找到 main 的地址，然后在 main 的第一条指令处设置一个断点。CPU 复位后，执行完 SystemInit、__main，一路跑到 main，撞上断点，暂停，把控制权交还给调试器。
但 Reset_Handler 不一样。
它是 CPU 复位后执行的第一条指令。在它之前，CPU 的 PC 还没有进入用户代码区域。调试器如果想停在 Reset_Handler，必须在 CPU 复位释放的那一瞬间 就让 PC 停住。
这需要一种不依赖软件执行的机制。
二、硬件断点：Cortex‑M3 内置的调试利器
Cortex‑M3 内核内置了一套调试组件，叫 CoreSight 调试架构。这套组件里有两个关键的模块：
- FPB（Flash Patch and Breakpoint Unit）：提供 6 个指令断点比较器（Cortex‑M4/M7 上是 8 个）。
- DWT（Data Watchpoint and Trace）：提供 2 个数据观察点比较器。
FPB 的每个比较器可以配置为指令断点：当 PC 匹配到某个地址时，触发调试事件，暂停 CPU。DWT 的比较器则可以配置为数据观察点：当某个内存地址被读写时，触发调试事件。
硬件断点的工作原理极其简单：
整个过程是纯硬件行为。 不需要修改 Flash 中的任何指令，不需要插入任何软件代码，不依赖目标 CPU 是否在执行。只要 CPU 试图从那个地址取指令，比较器就会抓住它。
这就是调试器停在 Reset_Handler 第一条指令的底层机制。 调试器在复位释放之前，通过 DAP 接口把 Reset_Handler 的地址写入 FPB 比较器，然后释放复位。CPU 第一次取指——取的就是 Reset_Handler 的第一条指令——地址匹配，硬件暂停。
三、软件断点：篡改指令换取无限数量
硬件断点好用，但数量有限。Cortex‑M3 只有 6 个硬件断点。如果你调试的程序逻辑复杂，需要设几十个断点，6 个根本不够。
这时候，调试器会切换到另一种机制：软件断点。
软件断点的原理同样简单，但路子完全不同：
软件断点的本质，是“以指令替换换取无限数量”。 因为 BKPT 指令只有 2 个字节，调试器可以在 Flash 或 RAM 的任意位置插入它，不占用硬件比较器。
但软件断点有一个致命限制：它需要修改目标内存的内容。
四、为什么软件断点不能用在 Reset_Handler 的第一条指令？
因为修改 Flash 需要擦写扇区，速度慢且磨损大。
调试器虽然可以通过 DAP 接口直接操作 Flash 控制器来修改 Flash 内容（这并不依赖于目标 CPU 是否初始化），但擦写一个扇区需要几十到几百毫秒。在调试启动阶段，调试器需要在 CPU 第一次取指时立刻将其停住，任何毫秒级的延迟都会让 CPU 跑过 Reset_Handler 的第一条指令，直接进入后续的初始化代码。
所以，调试器如果要在 Reset_Handler 的第一条指令处暂停，只能用硬件断点。 FPB 比较器在 CPU 复位后立刻生效，不需要任何软件配合，不需要修改任何内存内容，延迟为零。
那为什么调试器停在 main 时，用的是软件断点而不是硬件断点？
main 的地址通常在 Flash 中。修改 Flash 需要擦写扇区，速度慢且磨损大。更常见的做法是：调试器在 main 处优先使用硬件断点，前提是硬件断点还没用完。 只有在硬件断点用尽之后，调试器才退回到软件断点——此时它可能会将断点设在 RAM 中运行的代码上，而非直接修改 Flash。
那为什么有时调试器停在 main 会失败？ 如果你的工程跳过了 __main，或者 main 的地址在 RAM 中（比如 RAM 调试模式），而调试器在设软件断点时不小心破坏了 RAM 中的代码，就可能导致程序跑飞。这也是为什么有些工程师发现“加了断点程序就跑飞，去掉断点就正常”——软件断点篡改了指令，而那条指令恰好被别的路径执行到了。
五、还有一种方式：复位时暂停
除了硬件断点，Cortex‑M3 还支持一种更直接的“停在第一条指令”的方式：复位时暂停。
调试器可以通过 DAP 接口设置一个控制位，告诉 CPU：“复位释放后，不要立即开始执行，先停在第一条指令处。”
这个功能由 DHCSR（Debug Halting Control and Status Register） 的 C_DEBUGEN 和 C_HALT 位配合复位控制实现。调试器在复位释放之前，先把 CPU 置于调试暂停状态，然后释放复位。CPU 复位后的第一个动作不是取指，而是检查调试控制寄存器——发现暂停位有效，直接进入调试暂停状态，PC 停在 Reset_Handler 的地址上。
这种方式不需要消耗硬件断点，也不需要修改 Flash。 但它要求调试器在复位释放前完成这些设置，而且不同调试器对“复位时暂停”的实现细节略有差异。有些调试器（如 J‑Link）会默认使用这种方式，所以你发现即使没设断点，程序也停在 Reset_Handler 的第一行——这是调试器在帮你“自动暂停”。
六、一个真实的对比实验
用 J‑Link 连接 STM32F103，打开 J‑Link Commander，执行以下命令：
r ; 复位并暂停
mem32 0x08000000, 1 ; 读向量表第一项（SP 初始值）
regs ; 查看寄存器
你会发现 PC 的值不是 0x08000000，而是 Reset_Handler 的地址（比如 0x08000101）。SP 已经加载了 __initial_sp 的值。这说明 CPU 已经完成了硬件取 SP 和 PC 的动作，但在执行 Reset_Handler 的第一条指令之前停了下来。
再用 GDB 做同样的实验：
(gdb) monitor reset halt
(gdb) info registers
PC 同样停在 Reset_Handler 的地址。GDB 内部同样使用了 DAP 接口的复位暂停机制。
如果你在调试器里手动设一个硬件断点（hbreak），然后全速运行，CPU 撞上硬件断点会暂停。如果你用普通断点（break），调试器可能用软件断点实现（取决于地址是否在 RAM）。 你可以用 info breakpoints 查看断点类型，GDB 会标注每个断点是“hardware”还是“software”。
七、举一反三
Q1：为什么 Cortex‑M3 只有 6 个硬件断点？
这是成本和芯片面积的权衡。每个硬件断点比较器需要存储一个 32 位地址、一个比较逻辑电路。6 个比较器已经占用了 FPB 模块的一部分面积。对于大多数嵌入式调试场景，6 个硬件断点 + 无限个软件断点已经足够了。如果需要更多硬件断点，需要升级到 Cortex‑M4/M7（8 个）或使用外部调试器（如 J‑Trace）的高级功能。
Q2：软件断点会永久修改 Flash 吗？
不会永久修改，但若调试会话异常终止，残留的 BKPT 指令可能未被恢复。不过，调试器极少向 Flash 中写入软件断点，因此 Flash 残留 BKPT 的情况非常罕见。 更常见的风险是：在 RAM 中调试时，RAM 中残留的 BKPT 指令可能导致独立运行时程序卡死。这也是调试时正常、拔掉调试器后异常的原因之一。
Q3：在 RAM 中调试时，软件断点和硬件断点哪个更好？
在 RAM 中调试时，软件断点修改的是 RAM 内容，不需要擦写 Flash，速度快，且数量无限。所以 RAM 调试几乎全部使用软件断点。但要注意：RAM 中的代码如果被意外覆盖（比如栈溢出），软件断点也会被破坏。 硬件断点不受内存内容影响，在 RAM 调试中同样可靠，但数量有限。
八、写在最后
回到最初的问题：为什么调试器能停在 Reset_Handler 的第一条指令？
因为在 Reset_Handler 的第一条指令之前，没有任何软件在跑。调试器能依赖的，只有 Cortex‑M3 内核在硅片上蚀刻的那几个硬件断点比较器，以及 DAP 总线接口那几根调试信号线。
硬件断点是调试器在 CPU 最早期阶段的唯一抓手。 它不需要 Flash 可写，不需要 RAM 就绪，不需要任何软件配合。它只是在 CPU 的取指流水线旁，安静地等在那里。一旦 PC 的值和它预设的地址匹配，它就出手，把 CPU 按在第一条指令之前。
而复位暂停机制，更是在硬件断点之前就直接截停了 CPU。连地址比较都不需要，只要复位释放，就立即暂停。
这两种机制的共同点：它们都是硬件级的，都发生在用户代码执行之前，都不依赖任何软件初始化。这就是为什么调试器能抓住那条你永远抓不住的、CPU 一生中执行的第一条指令。
下一篇预告：《为什么有些启动 bug 在仿真时正常，烧录后异常？》——仿真器可能初始化了一些硬件，实际芯片没有。
关注「OneChan讲Soc嵌入式」，不错过后续 16 篇“为什么”。
