搞ZYNQ-7020调试的兄弟估计十有八九都撞过这么一堵墙Vitis里点开调试等半天结果弹出来一行报错说找不到目标设备或者干脆卡在连接阶段Target Manager里那个ARM DAP的图标死活不亮。我前阵子就在一块自制的7020板卡上被这事困了两天Vitis 2023.2、JTAG-HS3下载器hello world工程的elf都编译好了就是不往下走。后来一步步把硬件链路、hw_server、XSCT脚本全捋了一遍才定位到是板卡上PS_POR_B复位引脚的电平时序跟调试器初始化顺序有冲突。这类问题在7系列ZYNQ上非常典型尤其是从Vivado 2020.1之后版本切换到统一安装器、或者从SDK切到Vitis环境的朋友遇到无法识别ARM DAP的次数比想象中高得多。这篇就把我这次的排查过程、原理分析和解决手段完整写出来从硬件信号到软件工具链按层拆解希望能帮同样被卡住的人省点时间。1. 先搞懂ARM DAPVitis调试时到底在连什么很多人在这一步就懵了因为Vitis报错信息里经常出现DAP、Debug Hub、ARM CoreSight这些词但并不知道它们之间的关系。如果不理解Vitis访问目标的链路排查起来就是瞎猜一会儿怀疑硬件一会儿怀疑软件效率很低。1.1 报错背后的调试链路7系列ZYNQ的调试架构基于ARM CoreSight调试体系内部集成了DAPDebug Access Port调试访问端口。DAP不是一个单纯的寄存器块它由两部分组成DPDebug Port调试端口和APAccess Port访问端口。DP负责处理外部JTAG接口协议AP则负责连接到芯片内部的调试总线比如AXI-AP、MEM-AP等。Vitis调试时链路是这样的下载器比如Digilent JTAG-HS3通过USB连接到PCJTAG信号接到板卡的JTAG接口走TDI、TDO、TCK、TMS四根线进入ZYNQ的JTAG TAP。这个TAP就是DAP的对外窗口。Vitis侧通过hw_server这个后台服务进程跟下载器通信hw_server通过JTAG链路向DAP发送DPACC和APACC操作DAP再转发到AXI总线从而访问DDR、OCM、或者读取Cortex-A9核的状态寄存器。当你看到Vitis提示无法识别ARM DAP时通常是这条链路的某一环出了问题。有可能是JTAG接口根本没枚举到ZYNQ设备也有可能是枚举到了但DAP无法正常应答还有可能是DAP应答了但后续访问AP时得到了错误返回。不同环节出问题报错长得很不一样但只要理解了这条链路排查方向就很清晰。1.2 DAP与AP的区别决定排查方向DP和AP的分工是理解调试问题的关键。DP层负责最底层的JTAG交互比如读取IDCODE、写DPACC寄存器。AP层负责更高层的总线访问比如通过MEM-AP访问地址空间。如果DP层都过不去说明硬件连接或时钟有问题如果DP层能过、但AP层失败那问题可能在于目标系统没有初始化好比如AXI总线时钟没起、DDR控制器没配置。实际工作的时候我习惯先分两层去判断DP层失败表现为JTAG枚举能看到IDCODE但尝试访问DPACC寄存器时返回全F或超时。这通常和电源、参考时钟、复位有关。AP层失败表现为DPACC寄存器能读能写但AP中的MEM-AP或AXI-AP访问异常比如读DDR返回数据不对。这通常和PS端的时钟启动、MIO配置、或者DDR初始化代码有关。在Vitis的调试流程里它启动目标时会枚举JTAG设备如果第一步就失败会提示类似Device not found或Target connection failed如果第二步失败则会提示Cortex-A9 core无法halt或无法读取寄存器。注意很多人在7系列ZYNQ上遇到的DAP无法识别实际上是DP层的问题也就是外部条件没满足。这类问题往往不是Vitis配置错了而是板卡硬件层面的坑。2. 硬件排查先确认Target端活着软件工具链再强大也架不住硬件链路不通。我在做硬件调试排查时第一步永远是确认目标板卡的基本状态这个顺序不能乱不然容易把问题往复杂里想。2.1 电源与时序不要一上来就怀疑软件ZYNQ-7000的供电要求不算复杂但每一路都缺一不可。VCCINT、VCCAUX、VCCBRAM、VCCO、VCCPLL、VCCPAUX这些电源域的电压和时序必须满足要求。这里有个常见的坑PS端的VCCAUX和VCCPLL如果没供电或电压不对JTAG接口是有可能枚举出IDCODE的但DAP内部的逻辑无法正常工作导致后续调试失败。我自己做板卡习惯用示波器量一下上电时序确认VCCPLL和VCCPAUX在上电后保持稳定。VCCPLL是PS内部PLL的供电如果这个电压不稳PS_CLK即使有时钟内部逻辑也跑不起来。之前遇到过一块板卡VCCPLL上的电容焊错容值导致纹波过大Vivado Hardware Manager里能看到设备但Vitis怎么都连不上DAP排查了好久才发现是这里的问题。另外PS_POR_B信号非常关键。这个引脚是PS的复位输入低电平有效。调试器初始化ZYNQ时需要先释放PS_POR_BPS才能正常工作。很多自制板卡会用RC电路给PS_POR_B做上电延时复位如果R或C的取值不合理PS_POR_B释放时间太晚或者释放时存在抖动Vitis在枚举设备时会反复读到不稳定的状态。实测经验PS_POR_B的RC复位时间建议控制在10ms到100ms之间。太短了无法可靠复位太长了调试器在扫描设备时会因为复位未释放而识别不到DAP。2.2 JTAG信号完整性检查要点JTAG信号看着简单只有四根线加可选的地线但这几根线是最容易出问题的。用万用表量一下板卡上JTAG接口跟ZYNQ引脚之间的通断是最基础的。我之前遇到过JTAG连接器虚焊TMS引脚不通导致设备枚举时好时坏。除了通断还要注意JTAG信号的参考电平和上拉下拉电阻。ZYNQ的JTAG引脚位于特定的BANK这个BANK的VCCO电压必须和下载器输出电平匹配。比如ZYNQ-7020的JTAG引脚在BANK 500如果这个BANK的VCCO是3.3V但下载器是1.8V电平电平不匹配就会导致信号识别异常。JTAG信号建议按以下检查TDI、TDO、TCK、TMS四根线逐一量通断确认没有断路或短路。确认TCK、TMS、TDI有合适的上拉或下拉电阻。按照Xilinx官方建议TCK建议下拉TMS和TDI建议上拉TDO可以不处理。如果板卡上没有这些电阻下载器本身的驱动能力可能不足调试不稳定。量一下JTAG接口的VCCO参考电压是否正常。2.3 PS端复位与时钟的特殊性ZYNQ的PS有多个复位信号除了PS_POR_B之外还有PS_SRST_B和外部看门狗复位。PS_SRST_B作用范围比PS_POR_B小但同样会影响调试连接。在JTAG调试时如果PS_SRST_B一直被拉低内核无法运行DAP的某些寄存器访问也会失败。时钟方面PS_CLK是一个必须关注的信号。ZYNQ-7000本身需要一个PS_CLK输入时钟在没有配置PLL的情况下PS_CLK会直接作为PS内部模块的参考时钟。DAP本身对PS_CLK的依赖相对较低因为DAP可以通过JTAG时钟独立工作但很多AP访问操作比如通过AXI-AP访问DDR依赖PS内部的时钟已经初始化。如果PS_CLK根本没有起振Vitis大概率能枚举到JTAG上的ZYNQ设备IDCODE但访问CPU时就会失败因为CPU没有时钟跑不起来。所以排查时用示波器确认PS_CLK频率是否正常一般7系列ZYNQ用33.333MHz或其他频率但必须在数据手册规定的范围内。3. 软件环境排查从hw_server到Vitis的完整链路硬件状态确认无误之后如果还是识别不了ARM DAP那就要转到软件工具链这边来查了。不要再反反复复重启Vitis或者重新插拔调试器那个意义不大正确做法是逐层看工具的日志和状态。3.1 hw_server日志怎么读Vitis调试时启动的hw_server进程是PC和调试器之间的桥梁。它负责枚举下载器、扫描JTAG链路上的设备、以及处理Vitis发下来的调试命令。hw_server启动时会在终端或日志文件里输出当前扫描到的设备信息这些信息就是第一手的排查依据。在Vitis中可以在Flow Navigator里找到Xilinx - Program and Debug或者在终端里手动启动hw_server。手动启动的好处是能看到完整的日志输出不会因为GUI界面把细节吞掉。日志里最关键的几处下载器识别信息USB连接是否成功驱动是否加载。JTAG链扫描结果枚举出了哪些IDCODE链上设备的数量。设备匹配信息识别出的设备是否与Vitis工程期望的目标匹配。我这次遇到的情况hw_server日志里显示能识别到Xilinx的下载器但扫描JTAG链时链上只有一个非预期设备没有ZYNQ的IDCODE。这说明问题出在JTAG链路连接或目标设备本身。3.2 Vivado Hardware Manager和Vitis结果不一致怎么办这是个值得单说的问题。很多时候你会发现同一个下载器同一块板卡用Vivado Hardware Manager连接一切正常能看到ZYNQ设备也能读IDCODE但切到Vitis里调试就识别不到ARM DAP。如果出现这种情况反而说明硬件链路是通的问题出在Vitis的配置或版本匹配上。Vitis的调试目标配置是在工程里设置的。新版本的Vitis在创建调试配置时需要选择目标设备有时候这里选错了或者配置文件里记录的IDCODE与板卡实际IDCODE不匹配连接时就会失败。解决方法是手动检查调试配置的target设置删掉旧的重新扫描。另外Vivado和Vitis内置的hw_server版本如果不一致也可能导致问题。一个比较典型的情况是Vitis安装时没有选择安装Vivado的完整组件导致Vitis调用了一个旧版或缺失的hw_server。可以到安装目录下看hw_server的版本确认和Vivado版本匹配。3.3 Cable驱动与权限问题这个坑在Linux环境下尤其常见Windows下也偶尔碰到。Digilent的JTAG-HS3、Xilinx Platform Cable USB II这类下载器在Linux下需要安装对应的udev规则否则普通用户没有权限访问USB设备hw_server就无法打开下载器。Windows下常见的问题是驱动装错或者调试器插了多个hw_server选择了错误的设备。可以打开设备管理器查看调试器是否正确枚举为Jungo或Digilent设备而不是未知设备。如果条件允许建议在排查DAP问题前先做一次最简单的测试在Vivado Hardware Manager里打开硬件目标点击设备枚举看是否能看到ZYNQ的IDCODE。这个测试能帮你快速把问题切分到硬件链路还是Vitis工程配置。如果连Vivado都识别不到就不要再折腾Vitis了回头检查硬件和下载器。4. 用XSCT命令行手动探测DAPVitis的图形界面对排查问题不太友好因为它做了很多封装报错信息也模棱两可。真正高效的方式是直接用XSCTXilinx Software Command-Line Tool手动连接一步步探测DAP的状态。XSCT是Vitis底层调试引擎的shell命令能精确控制调试链路。4.1 连接、枚举的基本命令打开XSCT的方式是在Vitis的终端里输入xsct或者直接打开安装目录下的xsct可执行文件。启动后第一步是连接hw_serverconnect这个命令会让XSCT尝试连接默认本地hw_server服务。如果当前没有启动hw_server可以先启动再连接connect host localhost port 3121连接成功后用以下命令查看当前JTAG链上的所有目标targets这会列出链上的所有设备包括JTAG TAP、ARM核、以及其他调试组件。正常情况下应该能看到一个类似ARM Cortex-A9 MPCore的target。如果这里什么都没有或者只看到一个JTAG连接而没有任何ARM设备那么DAP的探测就失败了。4.2 手动访问AP与Memory如果targets命令能看到ARM核说明JTAG链路和DAP的DP层是好的。接下来可以尝试通过DAP访问内部存储或寄存器确认AP层是否正常。先选中ARM targettargets -set -filter {name ~ ARM*}然后尝试复位系统并读取寄存器rst rreg如果这些命令能正常返回说明DAP工作正常问题可能不在硬件而在Vitis工程配置。如果rreg卡住或报错说明AP层有问题需要进一步深入调试。我遇到过一种情况targets命令能看到ARM核但rreg返回数据全是0xFFFFFFFF这通常意味着DAP和AP之间的连接不稳定或者PS的时钟没有初始化好。此时可以尝试用bpsbreakpoint设置或mrdmemory read来进一步诊断mrd 0x00000000如果读取OCM地址空间返回异常基本可以确定PS内部时钟或总线接口没有正常启动。4.3 从日志反推问题出在哪一层XSCT执行每条命令时都会在后台输出交互日志可以通过设置日志级别来获取更多细节log -level debug调试级别的日志会显示DPACC和APACC操作的详细结果包括返回的ACK值。这里有个简单的判断法则如果DPACC操作返回的ACK不是OK二进制01说明DP层有问题。如果DPACC正常但APACC返回错误说明AP层有问题。用这个方法反推能把问题定位得非常准。大部分时候DP层出问题都逃不开供电、复位、JTAG信号这几个因素AP层出问题则偏向PS初始化、时钟、DDR配置这些软件层面的因素。5. 常见报错与排查速查表这次排查过程中我整理了几个ZYNQ调试时的典型报错和对应解决思路做成速查表遇到问题可以按图索骥。报错现象可能原因排查方向hw_server日志中无JTAG设备USB驱动/下载器连接问题检查设备管理器/udev规则更换USB口JTAG链枚举不到ZYNQ IDCODEJTAG信号通断、VCCO不匹配万用表量通断确认参考电压枚举到IDCODE但DAP无法访问PS_POR_B未释放、VCCPLL异常示波器查复位时序和电源纹波targets中没有ARM core调试配置选错设备、JTAG菊花链影响用Vivado Hardware Manager对比检查配置rreg返回全FAP层异常、PS时钟未初始化检查PS_CLK尝试rst -systemVitis报错Debug hub not detected调试配置中Target选择错误删除配置重新扫描核对IDCODE5.1 典型报错对照上面表格里列的几种情况我按从硬件到软件的顺序排了优先级。先确认供电再查JTAG线缆然后看复位信号最后才查Vitis配置。大多数卡在DAP无法识别的问题都能在这个顺序里找到答案。5.2 多板卡/多调试器场景如果你同时接了多块板卡或者多个调试器还会遇到目标冲突的问题。hw_server会把所有调试器上的设备都扫描出来Vitis默认连接第一个匹配的设备。有时候Vitis连上了A板卡但你实际要在B板卡上调试也会出现找不到目标的假象。XSCT里可以通过以下方式查看所有连接到的设备并手动选择targets -g在Vitis图形界面的Target Manager里也可以通过手动选择指定的调试器和设备来规避。5.3 烧写Flash与DDR依赖问题澄清关于网络热词里提到的ZYNQ 7020使用JTAG固化Flash时必须使用DDR吗这个问题我在这篇文章里简单澄清一下。JTAG固化Flash比如QSPI时通常不需要DDR参与因为固化流程是通过AXI-AP访问QSPI控制器完成的跟DDR没关系。但很多参考设计确实会先用一段初始化脚本设置PS端的引脚和时钟这段脚本运行在OCM里也不依赖DDR。如果你用了错误的FSBL或者初始化脚本固件里包含了DDR初始化的操作那编译、链接时不会报错但运行固化流程时可能会卡住因为DDR根本没有接或者没配好。这时Vitis的报错可能涉及DAP无法访问需要区分是真正的DAP问题还是初始化脚本的问题。经验之谈遇到固化Flash失败先确认初始化脚本里是否包含DDR相关的MIO配置。如果有可以把DDR初始化这一段注释掉再试能排除很大一部分干扰。6. 几点实操心得6.1 自制板卡的调试顺序如果你用的是自制板卡我在这次之后总结了一套固定的调试顺序分享出来第一步上电后先量所有供电轨确认电压和纹波在规格范围内。第二步用示波器确认PS_CLK有时钟PS_POR_B释放后有稳定的高电平。第三步在Vivado Hardware Manager里做JTAG识别测试确认能看到ZYNQ的IDCODE。第四步在XSCT里手动连接确认能枚举到ARM核并访问寄存器。第五步才打开Vitis的调试加载elf。这套顺序只需几分钟但能把硬件问题和工程配置问题彻底切分省下的时间远远超过这几分钟。6.2 版本兼容性是个隐形杀手这次遇到的问题之所以折腾了那么久有一个原因是Vitis 2023.2和之前一直使用的Vivado硬件服务器版本不匹配。安装Vitis时如果同时安装了VivadoVitis会调用自己的hw_server。但如果你的环境里既有旧版Vivado又在PATH里或者Vitis安装时勾选组件不全就会出现hw_server版本混乱的情况。排查这个问题可以查看进程里实际运行的hw_server路径和版本。这个细节平时不起眼关键时刻却能卡你一天。6.3 最后再分享一个小技巧在Vitis的Debug Configuration里如果遇到Target selection下拉框为空或选不到设备可以尝试在Target Manager里点击Add重新扫描一次。有时候是因为Vitis启动时hw_server还没有完全就绪GUI就刷新了列表导致目标列表为空。手动重新扫描往往能解决问题。另外使用第三方调试器的话建议每次更换调试器型号后删除旧的调试配置重新创建。Digilent、IXXAT、SEGGER等调试器的Target配置格式并不完全一样直接沿用旧配置很可能会踩到识别不出来的坑。
ZYNQ-7020调试报错ARM DAP无法识别？从硬件到软件全链路排查指南
搞ZYNQ-7020调试的兄弟估计十有八九都撞过这么一堵墙Vitis里点开调试等半天结果弹出来一行报错说找不到目标设备或者干脆卡在连接阶段Target Manager里那个ARM DAP的图标死活不亮。我前阵子就在一块自制的7020板卡上被这事困了两天Vitis 2023.2、JTAG-HS3下载器hello world工程的elf都编译好了就是不往下走。后来一步步把硬件链路、hw_server、XSCT脚本全捋了一遍才定位到是板卡上PS_POR_B复位引脚的电平时序跟调试器初始化顺序有冲突。这类问题在7系列ZYNQ上非常典型尤其是从Vivado 2020.1之后版本切换到统一安装器、或者从SDK切到Vitis环境的朋友遇到无法识别ARM DAP的次数比想象中高得多。这篇就把我这次的排查过程、原理分析和解决手段完整写出来从硬件信号到软件工具链按层拆解希望能帮同样被卡住的人省点时间。1. 先搞懂ARM DAPVitis调试时到底在连什么很多人在这一步就懵了因为Vitis报错信息里经常出现DAP、Debug Hub、ARM CoreSight这些词但并不知道它们之间的关系。如果不理解Vitis访问目标的链路排查起来就是瞎猜一会儿怀疑硬件一会儿怀疑软件效率很低。1.1 报错背后的调试链路7系列ZYNQ的调试架构基于ARM CoreSight调试体系内部集成了DAPDebug Access Port调试访问端口。DAP不是一个单纯的寄存器块它由两部分组成DPDebug Port调试端口和APAccess Port访问端口。DP负责处理外部JTAG接口协议AP则负责连接到芯片内部的调试总线比如AXI-AP、MEM-AP等。Vitis调试时链路是这样的下载器比如Digilent JTAG-HS3通过USB连接到PCJTAG信号接到板卡的JTAG接口走TDI、TDO、TCK、TMS四根线进入ZYNQ的JTAG TAP。这个TAP就是DAP的对外窗口。Vitis侧通过hw_server这个后台服务进程跟下载器通信hw_server通过JTAG链路向DAP发送DPACC和APACC操作DAP再转发到AXI总线从而访问DDR、OCM、或者读取Cortex-A9核的状态寄存器。当你看到Vitis提示无法识别ARM DAP时通常是这条链路的某一环出了问题。有可能是JTAG接口根本没枚举到ZYNQ设备也有可能是枚举到了但DAP无法正常应答还有可能是DAP应答了但后续访问AP时得到了错误返回。不同环节出问题报错长得很不一样但只要理解了这条链路排查方向就很清晰。1.2 DAP与AP的区别决定排查方向DP和AP的分工是理解调试问题的关键。DP层负责最底层的JTAG交互比如读取IDCODE、写DPACC寄存器。AP层负责更高层的总线访问比如通过MEM-AP访问地址空间。如果DP层都过不去说明硬件连接或时钟有问题如果DP层能过、但AP层失败那问题可能在于目标系统没有初始化好比如AXI总线时钟没起、DDR控制器没配置。实际工作的时候我习惯先分两层去判断DP层失败表现为JTAG枚举能看到IDCODE但尝试访问DPACC寄存器时返回全F或超时。这通常和电源、参考时钟、复位有关。AP层失败表现为DPACC寄存器能读能写但AP中的MEM-AP或AXI-AP访问异常比如读DDR返回数据不对。这通常和PS端的时钟启动、MIO配置、或者DDR初始化代码有关。在Vitis的调试流程里它启动目标时会枚举JTAG设备如果第一步就失败会提示类似Device not found或Target connection failed如果第二步失败则会提示Cortex-A9 core无法halt或无法读取寄存器。注意很多人在7系列ZYNQ上遇到的DAP无法识别实际上是DP层的问题也就是外部条件没满足。这类问题往往不是Vitis配置错了而是板卡硬件层面的坑。2. 硬件排查先确认Target端活着软件工具链再强大也架不住硬件链路不通。我在做硬件调试排查时第一步永远是确认目标板卡的基本状态这个顺序不能乱不然容易把问题往复杂里想。2.1 电源与时序不要一上来就怀疑软件ZYNQ-7000的供电要求不算复杂但每一路都缺一不可。VCCINT、VCCAUX、VCCBRAM、VCCO、VCCPLL、VCCPAUX这些电源域的电压和时序必须满足要求。这里有个常见的坑PS端的VCCAUX和VCCPLL如果没供电或电压不对JTAG接口是有可能枚举出IDCODE的但DAP内部的逻辑无法正常工作导致后续调试失败。我自己做板卡习惯用示波器量一下上电时序确认VCCPLL和VCCPAUX在上电后保持稳定。VCCPLL是PS内部PLL的供电如果这个电压不稳PS_CLK即使有时钟内部逻辑也跑不起来。之前遇到过一块板卡VCCPLL上的电容焊错容值导致纹波过大Vivado Hardware Manager里能看到设备但Vitis怎么都连不上DAP排查了好久才发现是这里的问题。另外PS_POR_B信号非常关键。这个引脚是PS的复位输入低电平有效。调试器初始化ZYNQ时需要先释放PS_POR_BPS才能正常工作。很多自制板卡会用RC电路给PS_POR_B做上电延时复位如果R或C的取值不合理PS_POR_B释放时间太晚或者释放时存在抖动Vitis在枚举设备时会反复读到不稳定的状态。实测经验PS_POR_B的RC复位时间建议控制在10ms到100ms之间。太短了无法可靠复位太长了调试器在扫描设备时会因为复位未释放而识别不到DAP。2.2 JTAG信号完整性检查要点JTAG信号看着简单只有四根线加可选的地线但这几根线是最容易出问题的。用万用表量一下板卡上JTAG接口跟ZYNQ引脚之间的通断是最基础的。我之前遇到过JTAG连接器虚焊TMS引脚不通导致设备枚举时好时坏。除了通断还要注意JTAG信号的参考电平和上拉下拉电阻。ZYNQ的JTAG引脚位于特定的BANK这个BANK的VCCO电压必须和下载器输出电平匹配。比如ZYNQ-7020的JTAG引脚在BANK 500如果这个BANK的VCCO是3.3V但下载器是1.8V电平电平不匹配就会导致信号识别异常。JTAG信号建议按以下检查TDI、TDO、TCK、TMS四根线逐一量通断确认没有断路或短路。确认TCK、TMS、TDI有合适的上拉或下拉电阻。按照Xilinx官方建议TCK建议下拉TMS和TDI建议上拉TDO可以不处理。如果板卡上没有这些电阻下载器本身的驱动能力可能不足调试不稳定。量一下JTAG接口的VCCO参考电压是否正常。2.3 PS端复位与时钟的特殊性ZYNQ的PS有多个复位信号除了PS_POR_B之外还有PS_SRST_B和外部看门狗复位。PS_SRST_B作用范围比PS_POR_B小但同样会影响调试连接。在JTAG调试时如果PS_SRST_B一直被拉低内核无法运行DAP的某些寄存器访问也会失败。时钟方面PS_CLK是一个必须关注的信号。ZYNQ-7000本身需要一个PS_CLK输入时钟在没有配置PLL的情况下PS_CLK会直接作为PS内部模块的参考时钟。DAP本身对PS_CLK的依赖相对较低因为DAP可以通过JTAG时钟独立工作但很多AP访问操作比如通过AXI-AP访问DDR依赖PS内部的时钟已经初始化。如果PS_CLK根本没有起振Vitis大概率能枚举到JTAG上的ZYNQ设备IDCODE但访问CPU时就会失败因为CPU没有时钟跑不起来。所以排查时用示波器确认PS_CLK频率是否正常一般7系列ZYNQ用33.333MHz或其他频率但必须在数据手册规定的范围内。3. 软件环境排查从hw_server到Vitis的完整链路硬件状态确认无误之后如果还是识别不了ARM DAP那就要转到软件工具链这边来查了。不要再反反复复重启Vitis或者重新插拔调试器那个意义不大正确做法是逐层看工具的日志和状态。3.1 hw_server日志怎么读Vitis调试时启动的hw_server进程是PC和调试器之间的桥梁。它负责枚举下载器、扫描JTAG链路上的设备、以及处理Vitis发下来的调试命令。hw_server启动时会在终端或日志文件里输出当前扫描到的设备信息这些信息就是第一手的排查依据。在Vitis中可以在Flow Navigator里找到Xilinx - Program and Debug或者在终端里手动启动hw_server。手动启动的好处是能看到完整的日志输出不会因为GUI界面把细节吞掉。日志里最关键的几处下载器识别信息USB连接是否成功驱动是否加载。JTAG链扫描结果枚举出了哪些IDCODE链上设备的数量。设备匹配信息识别出的设备是否与Vitis工程期望的目标匹配。我这次遇到的情况hw_server日志里显示能识别到Xilinx的下载器但扫描JTAG链时链上只有一个非预期设备没有ZYNQ的IDCODE。这说明问题出在JTAG链路连接或目标设备本身。3.2 Vivado Hardware Manager和Vitis结果不一致怎么办这是个值得单说的问题。很多时候你会发现同一个下载器同一块板卡用Vivado Hardware Manager连接一切正常能看到ZYNQ设备也能读IDCODE但切到Vitis里调试就识别不到ARM DAP。如果出现这种情况反而说明硬件链路是通的问题出在Vitis的配置或版本匹配上。Vitis的调试目标配置是在工程里设置的。新版本的Vitis在创建调试配置时需要选择目标设备有时候这里选错了或者配置文件里记录的IDCODE与板卡实际IDCODE不匹配连接时就会失败。解决方法是手动检查调试配置的target设置删掉旧的重新扫描。另外Vivado和Vitis内置的hw_server版本如果不一致也可能导致问题。一个比较典型的情况是Vitis安装时没有选择安装Vivado的完整组件导致Vitis调用了一个旧版或缺失的hw_server。可以到安装目录下看hw_server的版本确认和Vivado版本匹配。3.3 Cable驱动与权限问题这个坑在Linux环境下尤其常见Windows下也偶尔碰到。Digilent的JTAG-HS3、Xilinx Platform Cable USB II这类下载器在Linux下需要安装对应的udev规则否则普通用户没有权限访问USB设备hw_server就无法打开下载器。Windows下常见的问题是驱动装错或者调试器插了多个hw_server选择了错误的设备。可以打开设备管理器查看调试器是否正确枚举为Jungo或Digilent设备而不是未知设备。如果条件允许建议在排查DAP问题前先做一次最简单的测试在Vivado Hardware Manager里打开硬件目标点击设备枚举看是否能看到ZYNQ的IDCODE。这个测试能帮你快速把问题切分到硬件链路还是Vitis工程配置。如果连Vivado都识别不到就不要再折腾Vitis了回头检查硬件和下载器。4. 用XSCT命令行手动探测DAPVitis的图形界面对排查问题不太友好因为它做了很多封装报错信息也模棱两可。真正高效的方式是直接用XSCTXilinx Software Command-Line Tool手动连接一步步探测DAP的状态。XSCT是Vitis底层调试引擎的shell命令能精确控制调试链路。4.1 连接、枚举的基本命令打开XSCT的方式是在Vitis的终端里输入xsct或者直接打开安装目录下的xsct可执行文件。启动后第一步是连接hw_serverconnect这个命令会让XSCT尝试连接默认本地hw_server服务。如果当前没有启动hw_server可以先启动再连接connect host localhost port 3121连接成功后用以下命令查看当前JTAG链上的所有目标targets这会列出链上的所有设备包括JTAG TAP、ARM核、以及其他调试组件。正常情况下应该能看到一个类似ARM Cortex-A9 MPCore的target。如果这里什么都没有或者只看到一个JTAG连接而没有任何ARM设备那么DAP的探测就失败了。4.2 手动访问AP与Memory如果targets命令能看到ARM核说明JTAG链路和DAP的DP层是好的。接下来可以尝试通过DAP访问内部存储或寄存器确认AP层是否正常。先选中ARM targettargets -set -filter {name ~ ARM*}然后尝试复位系统并读取寄存器rst rreg如果这些命令能正常返回说明DAP工作正常问题可能不在硬件而在Vitis工程配置。如果rreg卡住或报错说明AP层有问题需要进一步深入调试。我遇到过一种情况targets命令能看到ARM核但rreg返回数据全是0xFFFFFFFF这通常意味着DAP和AP之间的连接不稳定或者PS的时钟没有初始化好。此时可以尝试用bpsbreakpoint设置或mrdmemory read来进一步诊断mrd 0x00000000如果读取OCM地址空间返回异常基本可以确定PS内部时钟或总线接口没有正常启动。4.3 从日志反推问题出在哪一层XSCT执行每条命令时都会在后台输出交互日志可以通过设置日志级别来获取更多细节log -level debug调试级别的日志会显示DPACC和APACC操作的详细结果包括返回的ACK值。这里有个简单的判断法则如果DPACC操作返回的ACK不是OK二进制01说明DP层有问题。如果DPACC正常但APACC返回错误说明AP层有问题。用这个方法反推能把问题定位得非常准。大部分时候DP层出问题都逃不开供电、复位、JTAG信号这几个因素AP层出问题则偏向PS初始化、时钟、DDR配置这些软件层面的因素。5. 常见报错与排查速查表这次排查过程中我整理了几个ZYNQ调试时的典型报错和对应解决思路做成速查表遇到问题可以按图索骥。报错现象可能原因排查方向hw_server日志中无JTAG设备USB驱动/下载器连接问题检查设备管理器/udev规则更换USB口JTAG链枚举不到ZYNQ IDCODEJTAG信号通断、VCCO不匹配万用表量通断确认参考电压枚举到IDCODE但DAP无法访问PS_POR_B未释放、VCCPLL异常示波器查复位时序和电源纹波targets中没有ARM core调试配置选错设备、JTAG菊花链影响用Vivado Hardware Manager对比检查配置rreg返回全FAP层异常、PS时钟未初始化检查PS_CLK尝试rst -systemVitis报错Debug hub not detected调试配置中Target选择错误删除配置重新扫描核对IDCODE5.1 典型报错对照上面表格里列的几种情况我按从硬件到软件的顺序排了优先级。先确认供电再查JTAG线缆然后看复位信号最后才查Vitis配置。大多数卡在DAP无法识别的问题都能在这个顺序里找到答案。5.2 多板卡/多调试器场景如果你同时接了多块板卡或者多个调试器还会遇到目标冲突的问题。hw_server会把所有调试器上的设备都扫描出来Vitis默认连接第一个匹配的设备。有时候Vitis连上了A板卡但你实际要在B板卡上调试也会出现找不到目标的假象。XSCT里可以通过以下方式查看所有连接到的设备并手动选择targets -g在Vitis图形界面的Target Manager里也可以通过手动选择指定的调试器和设备来规避。5.3 烧写Flash与DDR依赖问题澄清关于网络热词里提到的ZYNQ 7020使用JTAG固化Flash时必须使用DDR吗这个问题我在这篇文章里简单澄清一下。JTAG固化Flash比如QSPI时通常不需要DDR参与因为固化流程是通过AXI-AP访问QSPI控制器完成的跟DDR没关系。但很多参考设计确实会先用一段初始化脚本设置PS端的引脚和时钟这段脚本运行在OCM里也不依赖DDR。如果你用了错误的FSBL或者初始化脚本固件里包含了DDR初始化的操作那编译、链接时不会报错但运行固化流程时可能会卡住因为DDR根本没有接或者没配好。这时Vitis的报错可能涉及DAP无法访问需要区分是真正的DAP问题还是初始化脚本的问题。经验之谈遇到固化Flash失败先确认初始化脚本里是否包含DDR相关的MIO配置。如果有可以把DDR初始化这一段注释掉再试能排除很大一部分干扰。6. 几点实操心得6.1 自制板卡的调试顺序如果你用的是自制板卡我在这次之后总结了一套固定的调试顺序分享出来第一步上电后先量所有供电轨确认电压和纹波在规格范围内。第二步用示波器确认PS_CLK有时钟PS_POR_B释放后有稳定的高电平。第三步在Vivado Hardware Manager里做JTAG识别测试确认能看到ZYNQ的IDCODE。第四步在XSCT里手动连接确认能枚举到ARM核并访问寄存器。第五步才打开Vitis的调试加载elf。这套顺序只需几分钟但能把硬件问题和工程配置问题彻底切分省下的时间远远超过这几分钟。6.2 版本兼容性是个隐形杀手这次遇到的问题之所以折腾了那么久有一个原因是Vitis 2023.2和之前一直使用的Vivado硬件服务器版本不匹配。安装Vitis时如果同时安装了VivadoVitis会调用自己的hw_server。但如果你的环境里既有旧版Vivado又在PATH里或者Vitis安装时勾选组件不全就会出现hw_server版本混乱的情况。排查这个问题可以查看进程里实际运行的hw_server路径和版本。这个细节平时不起眼关键时刻却能卡你一天。6.3 最后再分享一个小技巧在Vitis的Debug Configuration里如果遇到Target selection下拉框为空或选不到设备可以尝试在Target Manager里点击Add重新扫描一次。有时候是因为Vitis启动时hw_server还没有完全就绪GUI就刷新了列表导致目标列表为空。手动重新扫描往往能解决问题。另外使用第三方调试器的话建议每次更换调试器型号后删除旧的调试配置重新创建。Digilent、IXXAT、SEGGER等调试器的Target配置格式并不完全一样直接沿用旧配置很可能会踩到识别不出来的坑。
