使用OpenOCD执行monitor reset run后GDB无法命中main断点的问题

核心原因：reset run与reset init的执行时序差异 #

你的问题本质是断点硬件配置的时机晚于程序执行到main的时间，而非reset run主动跳过断点：

• monitor reset run的执行逻辑
  这个命令会让MCU完成复位后立刻启动运行，全程没有CPU暂停阶段。而Cortex-M4复位后会先执行启动代码（初始化堆栈、搬运数据段、清零BSS等），很快就会跳转到main函数。
  你在复位前设置的硬件断点，会在MCU复位时被硬件寄存器清空；而复位后CPU立刻运行，GDB还来不及将断点重新写入MCU的硬件断点寄存器，程序就已经跑完启动代码进入main甚至直接越过了，所以无法命中。

• reset init的执行逻辑
  这个命令复位后会主动暂停CPU（通常停在复位向量指向的启动代码入口处）。此时CPU处于halt状态，GDB有足够时间将你设置的main断点同步到MCU的硬件断点寄存器中。之后执行continue，CPU从暂停处逐步执行，当运行到main时，硬件断点就会触发，程序停下。

操作调整建议 #

如果想通过reset run的方式命中断点，可以调整操作顺序：

1. 连接GDB到OpenOCD：target remote :3333
2. 执行monitor reset init（让CPU暂停在启动初期）
3. 设置main断点：break main
4. 执行monitor reset run
   此时断点已经提前写入硬件寄存器，复位后运行就能正常命中。

内容的提问来源于stack exchange，提问作者MBaev