4. Vitis调试器入门
在Zynq平台上，PS端的Cortex-A9是系统启动与业务调度的核心。硬件平台导出XSA后，Vitis会基于该硬件定义生成FSBL、应用工程与调试配置。调试器真正“接管”CPU之前，需要完成三件事：让Vitis知道目标硬件是什么、把可执行文件（ELF）放到正确的内存位置、在关键位置停下并观察寄存器与内存。本节围绕这三件事展开，重点说明调试配置的创建、ELF加载的地址语义、断点类型的选择，以及如何通过寄存器与反汇编判断Cortex-A9当前到底运行在哪里。
一、调试配置的创建与连接方式
在Vitis中，调试配置（Debug Configuration）本质上是“目标连接 + 初始化脚本 + 可执行文件”的组合。创建入口通常为 Run → Debug Configurations，选择 System Project Debug 或 Single Application Debug。对于Zynq-7000，常见连接方式有两种：一是通过JTAG直接连接芯片，由Vitis的初始化脚本完成DDR控制器、时钟与MIO的初始化；二是通过已有的FSBL或U-Boot，让目标先运行起来，再附加（Attach）到运行中的CPU。前者适合从零启动的裸机或FSBL调试，后者适合Linux用户态程序或已在运行的系统的在线诊断。
调试配置中几个关键字段需要明确：
- Project：选择要调试的应用工程，Vitis据此找到对应的ELF。
- Device / Target：选择具体的Zynq器件与JTAG链上的目标，多核时需指定Cortex-A9 #0 或 #1。
- Initialization File：通常是 ps7_init.tcl 或由XSA生成的初始化脚本，负责在连接前把PS的时钟、DDR、MIO配置到可用状态。
- Application：指定ELF路径，并勾选“Download”以在连接后自动下载。
- Reset Processor：决定连接时是否复位CPU。若目标已在运行且不希望打断，应关闭该选项并使用Attach。
一个容易忽略的点是：如果DDR尚未初始化，ELF中的 .text、.data 段无法被正确写入，调试器会报“memory write failed”或下载后PC指向非法地址。因此初始化脚本必须在下载ELF之前执行，且脚本中的DDR配置要与硬件设计一致。
二、ELF加载：地址、段与入口点
ELF（Executable and Linkable Format）不仅包含机器码，还包含段表、符号表与入口地址。Vitis下载ELF时，调试器读取Program Header，把各段按 p_paddr 写入目标内存。对于裸机工程，链接脚本（lscript.ld）通常把代码放在DDR的 0x00100000 附近，把栈放在DDR高地址；对于运行在OCM中的FSBL，代码可能位于 0x00000000 附近的OCM区域。加载是否成功，可以通过Vitis的Memory视图查看对应地址的内容是否与ELF一致来验证。
加载完成后，调试器会把PC设置为ELF的入口点（Entry Point），通常是 _start 或启动汇编的第一条指令。此时若直接Resume，CPU会从入口开始执行启动代码，完成栈指针设置、BSS清零、跳转到main。观察这一过程是理解Cortex-A9启动行为的最佳时机：可以在 _start 处设断点，单步执行几条指令，查看SP、LR、CPSR的变化。
三、断点类型与设置策略
Cortex-A9支持两类断点：软件断点与硬件断点。软件断点由调试器把目标地址的指令替换为断点指令（如BKPT或未定义指令），命中后再恢复原指令。它数量不受限，但只能设在可写的RAM区域，不能用于ROM或正在被DMA读取的代码。硬件断点使用CPU内部的断点比较器，Zynq-7000的Cortex-A9通常提供6个指令断点和4个数据断点，可设在任意地址，包括ROM与缓存中的代码。
实际调试中建议：
- 在 main、关键中断服务函数、状态机分支处使用软件断点，便于快速定位。
- 在启动汇编、ROM代码或DMA缓冲区相关代码处使用硬件断点。
- 数据断点（Watchpoint）用于监视某个全局变量被谁改写，例如监视DMA描述符或共享内存标志。
- 断点命中后先看Call Stack与寄存器，再决定单步或继续，避免盲目Step Over跳过关键分支。
四、观察Cortex-A9运行状态
断点命中后，Vitis的Registers视图会显示当前CPU的通用寄存器与状态寄存器。判断CPU运行状态时，重点看以下几组：
| 寄存器/视图 | 观察内容 | 典型判断 |
|---|---|---|
| PC | 当前指令地址 | 是否落在预期函数或异常向量内 |
| SP | 栈指针 | 是否在链接脚本分配的栈区间内，是否越界 |
| LR | 返回地址 | 判断函数调用来源 |
| CPSR | 模式位、中断屏蔽位 | 是否处于IRQ/FIQ模式，I/F位是否被屏蔽 |
| Disassembly | 反汇编与当前指令 | 确认PC处指令是否与源码一致 |
| Memory | 指定地址内容 | 验证ELF加载、变量值与DMA数据 |
当程序跑飞时，一个有效的排查顺序是：先看PC是否落在异常向量表（0x00000000 或 0xFFFF0000 附近），再看CPSR的模式位判断是数据 abort、预取 abort 还是未定义指令，然后查看DFSR/IFSR（若可访问）与LR，定位触发异常的指令地址。若PC停在 0x00000008 或 0x0000000C，通常意味着发生了异常并进入了向量入口。
五、一次完整的调试会话示例
假设有一个裸机工程，链接脚本把代码放在 0x00100000，栈顶为 0x001F8F00，main 中调用一个会触发数据异常的函数。调试过程可以这样组织：
- 创建 System Project Debug 配置，选择 Cortex-A9 #0，初始化脚本使用 ps7_init.tcl，Application 指向工程生成的 elf，勾选 Download 与 Reset Processor。
- 点击 Debug，Vitis 先执行初始化脚本，再下载 ELF，最后把 PC 停在 _start。此时在 Memory 视图输入 0x00100000，确认内容与反汇编一致。
- 在 main 处设置软件断点，Resume。命中后查看 Call Stack，确认调用路径为 _start → main。
- 在可疑函数入口设置第二个断点，继续运行。命中后单步执行，观察 R0–R3 与内存中指针的值。
- 若程序跳入异常向量，查看 PC 是否落在 0x00000008 附近，结合 CPSR 模式位与 LR 判断异常类型，再回到触发指令处修正指针或地址。
整个过程的关键不是“点了哪些按钮”，而是每一步都能回答：CPU现在在哪、为什么在这、下一步会去哪。调试配置决定连接与初始化，ELF加载决定代码与数据的落点，断点决定观察窗口，寄存器与内存视图则提供判断依据。把这四者串起来，Vitis调试器才真正成为定位Cortex-A9软硬件故障的有效工具。