调试基本原则：断点、单步执行、内存访问机制

做嵌入式调试这么多年，我养成了一个习惯：上手先确认目标设备支持什么类型的断点。这听起来很基础，但很多人踩过坑。你想想看，芯片跑起来了，程序却卡在某个位置不动了——原因多半不是代码逻辑，而是断点本身出了问题。这一章我们就把断点、单步执行和内存访问机制彻底理清楚。

断点的工作原理

断点本质上是让CPU在执行到指定位置时“停一下”。实现方式分两种：软件断点和硬件断点。区别非常关键。

特性	软件断点	硬件断点
实现原理	替换指令为0xCC（x86 INT3）	使用CPU调试寄存器（DR0~DR3）
是否修改代码	是	否
适用场景	RAM中运行的程序、Flash可写	ROM/Flash只读区域、中断向量表
数量限制	理论上无限（受Flash写入次数影响）	通常4个（ARM Cortex-M为6个）
实时性影响	高（执行0xCC触发异常）	低（硬件直接比较地址）

我在项目中遇到过这样的问题：把断点打在Flash里的启动代码上，结果程序每次跑到那里直接复位——因为0xCC替换了有效指令，芯片误判为非法操作。后来换用硬件断点就正常了。所以记住：只读区域必须用硬件断点。

单步执行机制

单步执行是让CPU每执行一条指令就暂停一次。有两种实现方式：

• 硬件单步：设置CPU的TF标志（Trap Flag），每条指令执行后自动触发调试异常。速度极快，但需要CPU支持。
• 软件单步：调试器在每条指令后临时插入INT3，执行完当前指令后命中下一个断点。效率低，但兼容性好。

我个人习惯用“逐语句”跟踪函数内部逻辑，用“逐过程”跳过那些已经验证过的库函数。比如调试一个UART驱动时，我会在uart_send_byte()函数入口设断点，单步进去看寄存器操作，但碰到delay_us()就直接逐过程跳过——省时间。

内存访问断点

内存访问断点不是“停在代码的某一行”，而是“停在访问某个内存地址的那一行”。它利用CPU的硬件监视点（Watchpoint）实现，通常与硬件断点共用寄存器。

• 读监视：一旦程序读取指定地址，立即暂停。
• 写监视：程序写入该地址时暂停。
• 读/写监视：任一种访问都触发。

举个例子。我曾经调试一个内存越界问题，全局数组buffer[64]总是被莫名其妙覆盖。我在buffer[0]上设了一个写监视断点，结果发现是DMA控制器在配置错误时把数据写到了相邻区域。如果没有内存访问断点，这种偶发问题可能要查好几天。

三种机制的协同使用

实际调试时，我经常把这三种机制组合起来：

1. 在可疑函数入口设置软件断点（因为数量不限）。
2. 程序停住后，用单步执行走到关键赋值语句前。
3. 在目标变量上添加内存访问断点，然后恢复运行。

这样一来，只要变量被修改，CPU立刻暂停，我就能看到现场。你想想看，如果只靠软件断点，你永远不知道那个变量是在哪条语句被改写的。

这张图展示了整个调试流程的走向。你注意看，内存访问断点其实是硬件断点的一个“变体”——它不监听指令地址，而是监听数据地址。这一点很多人用错了。