3. 软件调试入门：断点设置与单步执行、变量监视与内存查看、调用栈分析

软件调试，说白了就是让代码“慢下来”，让你能看清每一行指令到底干了什么。很多新手拿着仿真器，上来就点“全速运行”，出了问题一脸懵。我个人的习惯是：先让代码停下来，再问它为什么。

这一章，我们就来聊聊调试器最核心的三个基本功——断点、单步、变量与内存查看，以及调用栈分析。掌握了这些，你才算真正入了调试的门。

3.1 断点设置：让代码停在你想停的地方

断点不是随便乱下的。你得想清楚：我想观察哪一段逻辑？

3.1.1 普通断点 vs 条件断点

举个例子。你怀疑一个循环在第100次时出了问题。如果下普通断点，你得手动按99次“继续”。烦不烦？条件断点就派上用场了：

// 假设这是你的循环
for (int i = 0; i < 1000; i++) {
    process_data(i);
}

在调试器里，右键断点，设置条件为 i == 100。调试器会自动帮你停在那一次。嗯，省心多了。

3.1.2 数据断点（Watchpoint）

有时候你不需要知道代码停在哪一行，而是想知道某个变量什么时候被改了。这就是数据断点的用武之地。

我曾经遇到一个bug：一个全局变量莫名其妙被改成了0xDEAD。翻遍代码都找不到谁在写它。后来我下了个数据断点，条件设为“当该变量值变化时暂停”。结果发现是一个野指针越界写到了这个变量的地址上。这种问题，靠肉眼审查代码，三天都未必找得到。

3.2 单步执行：跟着代码一步一步走

断点只是“停车”，单步才是“慢放”。调试器里常见的单步操作有四种，很多人分不清它们的区别。

你想想看，如果你在 main() 里调了一个 uart_send()，你只是想确认发送流程对不对，没必要钻进 uart_send() 内部去看寄存器操作吧？这时候用 Step Over 就对了。

反过来，如果你怀疑 uart_send() 内部的某个判断逻辑有bug，那就用 Step Into 钻进去看。

3.3 变量监视与内存查看

单步执行的时候，眼睛盯着代码是不够的。你得同时盯着变量和内存的变化。

3.3.1 变量监视窗口

大多数IDE（如IAR、Keil、VS Code + Cortex-Debug）都提供Watch窗口。你可以把关心的变量拖进去，实时看它的值变化。

我个人习惯把变量分成三类来监视：

• 局部变量：当前函数的临时变量，通常自动显示在Locals窗口。
• 全局变量：跨函数共享的状态，手动添加到Watch。
• 表达式：比如 buffer[head]、*(uint32_t*)0x40020000，直接写表达式看结果。

举个例子，你怀疑一个环形缓冲区的头尾指针不同步：

// 在Watch窗口添加这两个表达式
head
tail
(head == tail) ? "Empty" : "Has Data"

单步执行时，看着这两个值的变化，问题往往一目了然。

3.3.2 内存查看窗口

变量监视看的是“逻辑值”，内存查看看的是“原始字节”。这两者有时候不一样。

比如你定义了一个结构体：

typedef struct {
    uint8_t id;
    uint32_t counter;
    uint16_t flags;
} __attribute__((packed)) my_packet_t;

在Watch窗口里，你看到 counter = 0x12345678。但在Memory窗口里，你看到的可能是 78 56 34 12（小端模式）。如果你要通过串口把这个结构体发出去，就必须知道它在内存里的真实排列。

3.4 调用栈分析：谁叫了谁？

程序跑飞了，或者卡在某个地方不动了。你暂停调试器，第一件事不是看代码，而是看调用栈（Call Stack）。

调用栈告诉你：当前CPU正在执行哪个函数？这个函数是谁调用的？一路往上追溯到main()。

3.4.1 读懂调用栈

一个典型的调用栈长这样（从上到下，从当前函数到入口）：

HardFault_Handler()      // 当前停在这里
uart_isr()               // 中断服务函数
main()                   // 主函数
Reset_Handler()          // 复位入口

看到这个栈，你就能推断出：程序在 uart_isr() 里触发了硬件错误，然后跳到了 HardFault_Handler()。问题大概率出在串口中断服务函数里。

3.4.2 栈回溯的常见场景

3.5 知识体系：软件调试核心流程

下面这张图，是我自己总结的软件调试基本流程。每次遇到问题，我都会按这个思路走一遍。

3.6 实战案例：一个典型的调试过程

光说不练假把式。我们来看一个我实际处理过的案例。

现象：设备运行几分钟后，串口输出乱码，然后死机。

调试步骤：

1. 下断点：在串口发送函数 uart_send_byte() 入口下普通断点。
2. 全速运行：等待断点触发。发现触发频率正常，排除发送函数本身的问题。
3. 下数据断点：在发送缓冲区指针 tx_buffer 上下数据断点，条件为值变化。
4. 再次运行：断点很快触发。查看调用栈，发现是一个定时器中断服务函数在修改 tx_buffer。
5. 分析代码：原来定时器ISR里有一个 memcpy 操作，目标地址计算错误，写到了 tx_buffer 的头上。
6. 修复：修正地址偏移量，重新测试，问题解决。

整个过程不到10分钟。如果没有数据断点和调用栈，我可能得花半天去一行行读代码。