Zynq SDK裸机开发中GDB调试的常见问题与实战技巧

1. 为什么说GDB是Zynq裸机调试的“定海神针”？

如果你刚开始接触Zynq的裸机开发，大概率会被SDK里各种调试选项搞得晕头转向。System Debugger、GDB、QEMU……到底该选哪个？我刚开始那会儿，也是哪个都试试，结果就是调试断点经常失灵，程序跑飞了也不知道卡在哪里，那种感觉就像在漆黑的房间里找钥匙，全靠运气。后来踩了无数坑才明白，对于裸机应用调试，GDB模式才是最稳定、最可靠的选择。为什么这么说？因为System Debugger模式在裸机环境下，对断点的支持非常不稳定，很多时候你明明打了断点，程序却像没看见一样直接跑过去了，调试会话形同虚设。而GDB作为老牌的、经过千锤百炼的调试器，它与Zynq处理器的JTAG接口配合得更为紧密，能够精确地控制处理器的执行流，说停就停，说走就走，这才是调试该有的样子。

所以，我的第一条实战经验就是：在SDK里创建调试配置时，毫不犹豫地选择“Xilinx C/C++ application (GDB)”。别再去折腾System Debugger了，那会浪费你大量时间。GDB调试的流程也很直观：在Project Explorer里右键你的应用工程，选择“Debug As” -> “Debug Configurations…”，然后在弹出的窗口里，找到“GDB”选项，双击创建一个新的配置。这里有个关键点，为了确保每次调试都从一个干净的状态开始，我强烈建议你勾选上“Reset entire System”这个选项。这个选项位于调试配置的“Application”选项卡里。勾选它之后，每次点击调试按钮，SDK都会通过JTAG命令让整个Zynq芯片（包括PS和PL）进行一次完整的复位，然后再下载程序。这能解决一大类“玄学”问题，比如修改代码后重新调试，中断死活进不去，或者程序莫名其妙跑飞。很多时候，硬件状态残留就是罪魁祸首，一个完整的系统复位能帮你省下大量排查时间。

2. 中断时有时无？先检查这两个配置

中断进不去，或者时灵时不灵，这绝对是Zynq裸机开发里最让人头疼的问题之一。我遇到过最诡异的情况是，代码一个字没改，只是重新编译下载了一次，中断就再也不触发了。折腾了半天，最后发现问题的根源往往不在中断服务函数本身，而在一些基础的配置和启动流程上。

首先，务必确认你的中断控制器已经正确初始化并启用。 对于Zynq的PS部分，中断控制器是GIC（Generic Interrupt Controller）。很多基于Xilinx BSP（Board Support Package）的模板代码会帮你做好这部分，但如果你是从更底层的代码开始，或者修改了BSP设置，就需要仔细检查。一个典型的初始化序列包括：调用 XScuGic_CfgInitialize 初始化GIC驱动实例，调用 XScuGic_Connect 将具体的中断ID（比如私有定时器中断是29）和你写的中断服务程序（ISR）连接起来，最后调用 XScuGic_Enable 在GIC层面启用这个中断。别忘了，在连接中断之前，还需要通过 Xil_ExceptionInit 和 Xil_ExceptionRegisterHandler