📚 课程目录第4章软件调试基础

4. 软件调试基础：Xilinx SDK/Vitis 调试器、断点设置、变量监视、内存查看

好，咱们进入软件调试环节。很多同学觉得调试就是点个“运行”按钮，看结果对不对。其实不然。调试是跟硬件对话的过程，尤其是在 Zynq 这种异构平台上，你不仅要看 ARM 跑得对不对，还得盯着 FPGA 那边的状态。

我个人习惯把调试分成三层：源码级（看 C 代码）、汇编级（看指令流）、内存级（看物理数据）。今天咱们先啃第一层——源码级调试。这是最常用的，也是你遇到问题时的第一道防线。

4.1 调试器界面：别被花哨的按钮吓住

打开 Vitis（或者老版本的 SDK），连上开发板，点那个小瓢虫图标进入调试透视图。你可能会看到一堆窗口：

Debug 窗口：显示调用栈和线程状态
编辑器窗口：显示当前断点位置的源码
Variables 窗口：显示局部变量和全局变量
Memory 窗口：显示指定地址的内存内容
Registers 窗口：显示 ARM 内核寄存器

嗯，这里要注意：别一上来就盯着所有窗口看。我刚开始带项目时，有个同事把十几个窗口全打开，结果自己都找不到代码在哪。你只需要保留 Debug、Variables、Memory 三个窗口就够了。其他的可以关掉，需要时再打开。

我的习惯：调试前先把 Variables 窗口的“显示类型”和“显示格式”调好。整数默认十进制，指针默认十六进制。这样一眼就能看出数据对不对。

4.2 断点设置：不是越多越好

断点分好几种。咱们先看最常用的：

断点类型	触发条件	适用场景
行断点	执行到指定行	检查某段逻辑是否被执行
条件断点	满足表达式条件	循环中只关心特定迭代
硬件断点	访问指定内存地址	检测变量被意外修改
Watchpoint	内存读写触发	跟踪指针越界

我在项目中遇到过一个问题：一个全局变量莫名其妙被改了，查了两天没找到原因。后来用了硬件断点，设置成“当地址 0xFFFF0000 被写入时暂停”，结果发现是 DMA 传输越界写到了那个区域。硬件断点在这种场景下就是神器。

注意：Zynq 的 ARM Cortex-A9 只有 6 个硬件断点寄存器。别设太多硬件断点，否则调试器会报错。软件断点没有数量限制，但会影响实时性。

4.3 变量监视：别只看值，要看地址

Variables 窗口里能看到当前作用域的所有变量。但很多人只看值，不看地址。我建议你养成一个习惯：右键变量 → 选择“Add to Expressions”，然后在 Expressions 窗口里同时看值和地址。

举个例子：

int buffer[1024];
int *ptr = buffer;

// 调试时，在 Expressions 里添加：
// buffer    -> 显示数组首地址
// ptr       -> 显示指针值
// *ptr      -> 显示指针指向的内容
// buffer[0] -> 显示数组第一个元素

这样你就能一眼看出指针有没有指向正确的位置。我曾经带过一个实习生，他调试时发现 buffer[0] 的值不对，查了半天，最后发现是 ptr 指向了 buffer+1，偏移了一个单位。如果只看值不看地址，这种问题很难发现。

4.4 内存查看：直接跟硬件对话

Memory 窗口是调试的终极武器。它能让你直接看到物理内存里的数据，不受 C 语言类型系统的干扰。

打开 Memory 窗口后，输入你想查看的地址。我常用的几个地址：

0x00000000：DDR 内存起始地址（看全局变量）
0xFFFF0000：OCM（片上内存）地址（看 BootROM 和 FSBL）
0x43C00000：AXI GPIO 的寄存器地址（看 FPGA 侧的状态）
0xE000A000：UART 寄存器地址（看串口状态）

你想想看，当你的程序跑飞了，或者变量值不对，你直接去内存里看原始数据，比在 C 代码里猜要快得多。

  避坑指南：我曾经调试一个网络协议栈，发现接收到的数据包总是少 4 个字节。用 Memory 窗口一看，发现 DMA 描述符里的长度字段被写错了。如果只看应用层的 buffer，永远找不到问题。

4.5 调试流程：从断点到内存的完整链路

下面这张图展示了调试时数据流动的完整链路。你可以把它贴在工位上：

调试器通过 JTAG 接口控制 ARM 内核。当你设置断点时，调试器会在目标地址插入一条 BKPT 指令（软件断点）或者配置硬件断点寄存器。当 CPU 执行到断点位置时，会触发异常，调试器捕获到异常后暂停 CPU，然后读取内存和寄存器数据展示给你看。

4.6 实战技巧：调试裸机程序时的常见问题

调试裸机程序跟调试 Linux 应用不太一样。裸机程序没有操作系统帮你管理内存，也没有虚拟地址映射。你看到的内存地址就是物理地址。这里有几个我踩过的坑：

断点打不上：检查代码是否在 OCM 里运行。OCM 是只读的，不能插入软件断点。改用硬件断点。
变量值不更新：检查编译器优化级别。O2 以上优化会把变量优化掉，或者放到寄存器里。调试时建议用 O0。
内存查看显示乱码：检查地址是否对齐。ARM 是 32 位处理器，访问未对齐地址会触发异常。
调试器连接不上：检查 JTAG 时钟频率。频率太高会导致信号不稳定，降到 5MHz 试试。

我的经验：调试裸机程序时，我习惯在 main 函数第一行设一个断点。这样能确保程序从正确的入口开始执行。如果连 main 都没进去，那问题大概率在 FSBL 或者链接脚本里。

4.7 小结

调试不是玄学，是科学。掌握好断点、变量监视和内存查看这三个工具，你就能解决 90% 的软件问题。剩下的 10%，咱们后面几章会讲到——那些跟 FPGA 交互相关的疑难杂症。

记住：先看内存，再看代码。内存不会骗人，代码可能会。