把 USB-JTAG 下载器插到板子上打开 Vivado Hardware ManagerTarget 列表里刷出来的不是期望的 xc7z020而是一串 00000000或者设备认到了Program Device 也报告成功可板上 DONE 灯就是不亮PS 端连串口打印都没有。这类问题我在调板过程中遇到过不止一次最后发现每次都不是 bit 流的问题也不是 RTL 代码的问题而是三个特别容易被忽略的物理和配置条件在捣乱JTAG 的 VREF 参考电压、芯片的启动模式引脚、以及上电复位时的时序握手。这篇文章把这三条隐藏条件一条条拆开讲透并且给出一套从 Vivado Hardware Manager 界面到示波器探头的完整排查流程帮你把原本可能花一下午的定位过程压缩到半小时以内。1. 现象背后的真相Hardware Manager 认识芯片不等于 FPGA 能正常启动1.1 JTAG 连接和 FPGA 启动本质上是两条不同的链路很多新手甚至不少有经验的工程师会把“JTAG 能连接上”和“FPGA 能启动”画上等号这是一个非常危险的误解。要理解为什么得先分清两条链路。第一条链路是 JTAG 边界扫描链路。USB 口出来经过下载器转成 TCK、TMS、TDI、TDO 四根信号进入 FPGA 的 TAP 控制器。TAP 控制器是芯片内部一个独立于配置数据路径的状态机它只需要 TAP 电源域工作就能响应指令。Hardware Manager 里 的 Auto Connect、IDCODE 读取、设备列表扫描全部走的是这条链路。第二条链路是 FPGA 的配置启动链路。上电后芯片内部 POR 复位释放 PROGRAM_B 引脚配置逻辑开始采样启动模式引脚然后根据模式从 JTAG、SPI Flash、SD 卡或其它源加载配置数据加载完成后内部 CRC 校验最后拉高 DONE进入用户模式。这两条链路在芯片内部共享一部分引脚和电源域但逻辑上是可以“半通”的。TAP 控制器活着不代表配置状态机是健康的。我见过太多情况Hardware Manager 能读到 IDCODE看着一切正常但 FPGA 实际上从未进入用户模式DONE 引脚被外部电路或者启动模式卡死在低电平。这也是我要写这篇文章的原因——你在图形界面上看到的“成功”往往只是一个局部成功。1.2 把失败现象分成三类定位效率立刻翻倍我先给故障分个类后面所有排查都围绕这三类展开。这是我在工作室白板上反复用过的一张表现在直接放出来给你参考。故障类型表面现象本质原因方向A 类链路完全不通Open Target 失败目标列表为空提示 no cable / no targetUSB 驱动、下载器损坏、TDI 到 TDO 链路断裂、VREF 完全没接B 类链路能通但数据混乱目标能打开设备列表读出 00000000 或 Unknown Device或 IDCODE 时对时错VREF 电平异常、TCK 频率过高、扫描链上其它器件未供电C 类链路正常启动失败IDCODE 正确Program 报告成功但 DONE 不亮、功能不工作、上电后反复失败BOOT_MODE/M 启动模式错误、上电时序违反、PROGRAM_B/DONE 被外部电路钳位你会发现A 类和 B 类问题大多集中在 JTAG 物理链路本身C 类问题才是真正意义上的“启动失败”。而本文要讲的三个隐藏条件里前两个VREF、启动模式分别对应 B 类和 C 类第三个上电时序是 C 类里最隐蔽的元凶。把这些条件提前排掉很多疑难杂症根本不会发展到让人挠头的地步。1.3 为什么这三个条件算“隐藏”因为它们不在报错文本里Vivado 的报错信息其实很“诚实”但它只能报出它能观测到的东西。如果 VREF 电压接错适配器感知到的逻辑电平阈值不对Hardware Manager 可能会报出“设备不支持”或者“IDCODE 无效”但不会告诉你“你的 VREF 电压错了”。如果启动模式引脚被板上的拨码开关设成了 QSPI 启动而 Flash 里是空的Hardware Manager 只会看到 FPGA 一直在等配置数据最多给你一个超时不会告诉你“请检查拨码开关”。这三个条件都是在设计的原理图、PCB 布局、硬件上电顺序里埋下的坑Vivado 作为软件工具只能看到结果看不到原因。所以它们不是软件能自动检测出来的必须靠人带着清单去查。下一节开始我按优先级一个一个拆。2. 隐藏条件一VREF 参考电压没给对JTAG 链路的“高电平”就是空中楼阁2.1 VREF 的物理作用以及最常见的接法先说清楚 VREF 是什么。在 Digilent HS3、Xilinx Platform Cable USB II 这类下载器上都会有一个名为 VTref 或者 VREF 的引脚。这个引脚的作用是让下载器感知目标板上的 I/O 电压水平。下载器内部的输出驱动器会根据 VREF 的电压值调整 TCK、TMS、TDI 这些输出信号的逻辑电平同时也会参考 VREF 来判断 TDO 回传信号的高电平阈值。打个比方VREF 就相当于两个人的握手暗号。你和对方约好了用 3.3 V 来表示“1”结果 VREF 给下载器报了一个 1.8 V下载器就会按 1.8 V 的门限去驱动信号对 3.3 V 的 FPGA 来说这个信号可能根本够不到高电平的门限握手自然就崩了。最常见的正确接法是把 VREF 引脚连接到 FPGA 的 Bank 0 的 VCCO 电压上。FPGA 的配置引脚包括 JTAG 引脚在电气上归 Bank 0 管Bank 0 的供电电压决定了这些引脚的实际 I/O 电平。7 系列和 Zynq-7000 的 Bank 0 通常工作在 3.3 V 或 2.5 V少数板子用 1.8 V。设计上 VREF 和 VCCO_0 直接相连是最稳妥的方案。但问题恰恰出在这里很多板子在调试阶段VCCO_0 这路电源压根就没被正确使能或者供电顺序还没调好而 VREF 又直接从 VCCO_0 上取于是 VREF 就是 0 V。TAP 控制器只要 VCCAUX 有电就能工作所以 JTAG 链路上其他信号是活的但下载器的输出驱动参考电压是 0整个 JTAG 链路实际处于“悬空”状态。2.2 VREF 异常时的三种典型表现对照你的现场情况VREF 异常不会每次都报同样的错它有三种典型表现你可以对照一下自己遇到的现场第一种链路完全识别不到。VREF 为 0 V 或者过低时下载器根本不知道目标板上的高电平是几伏TCK/TMS 信号驱动不出去Hardware Manager 直接报连接失败。这种情况最容易被人误判成“下载器坏了”或者“USB 线有问题”。第二种IDCODE 读了全零或者随机值。这种情况最迷惑人因为你说它完全不通吧偶尔又能扫到一点影子你说它通了吧读出来的设备列表根本不对。实质是信号电平处在逻辑阈值边缘采样结果不稳定。我遇到过一次同一个板子上午能连下午不能连最后发现是实验室空调温度变化导致某个电平裕量本来就很小的电路彻底飘了。第三种连接正常、IDCODE 正确但 Program 到一半失败。很多人不理解为什么 VREF 会影响编程因为编程过程中大量数据要通过 TDI/TMS 移位进入芯片任何一个 bit 的电平没有达到门限就会导致移位数据错位。数据一旦错位芯片内部的状态机立刻乱套报错信息千奇百怪。这种问题用示波器看 TCK/TMS 波形最容易暴露如果波形幅值明显偏低或者上升沿有明显台阶基本就是 VREF 没接对。2.3 从原理图到示波器VREF 的排查与修复实操如果现场遇到类似问题我建议按这个顺序查先看原理图JTAG 连接器上有没有 VREF 引脚。很多自制的 JTAG 排针只有 2x5 共 10 脚里面第 1 脚右上角往往就是 VTref。找到后确认它连到哪里去了。用万用表直流电压档量 VREF 对地电压。对 7 系列和 Zynq-7000 的板子正常情况下应该等于 Bank 0 的 VCCO。如果测出来是 0 V先查这路电源是否使能再查这一路电源的 LDO/DC-DC 有没有输出。如果 VREF 和 VCCO_0 是分开的就要确认板子上是否有跳线帽或者零欧电阻把它们连起来。我见过不少板子原理图里画了“SB1 默认断开”结果焊接时没焊整个调试阶段 JTAG 都不稳定。用示波器看 TCK 波形。正常情况应该是干净的数字方波高电平接近 VCCO低电平接近 0 V。如果看到高电平只有 1.5 V 左右而 VCCO 是 3.3 V几乎可以断定 VREF 环节出了问题。临时修复的办法如果 VCCO_0 已经正常输出 3.3 V可以用一根飞线把 VCCO_0 接到 VREF 引脚上然后重新扫描。这个方法虽然不优雅但在调试阶段非常有效能快速验证是不是 VREF 的问题。注意有些板载下载器比如 FT2232 方案的不一定有独立的 VREF 引脚它的 I/O 电平直接由板上的 3.3 V 供电决定。这种情况下 VREF 问题出现的概率会低一些但不代表没有——如果 FPGA 的 Bank 0 用的不是 3.3 V而是 1.8 V 或 2.5 VFT2232 的固定 3.3 V 输出依然存在电平不匹配的问题。这种设计我会在画板阶段就尽量避免。3. 隐藏条件二BOOT_MODE/M 引脚把芯片领上了一条错误启动路径3.1 启动模式引脚是上电瞬间被“定格”的一排开关FPGA 支持多种配置源JTAG、SPI Flash、BPI Flash、SD 卡、SelectMAP 等。芯片在上电复位释放之后做的第一件事不是配置自己而是采样启动模式引脚。对 7 系列 FPGA 来说这个引脚组叫 M[2:0]对 Zynq-7000 来说对应的是 BOOT_MODE 引脚实际是 MIO[5:4] 为主的一组信号。它们在上电瞬间被采样后就决定了后续配置数据要从哪个口进来。这里有一个关键认知这个采样只在特定的复位释放窗口内有效。也就是说你把板子断电重来模式引脚才重新采样如果你用 JTAG 在线下载 bit 流软件并不会去重新触发这个采样过程它走的是 TAP 控制器指令跟启动模式没有直接关系。这里面就藏着一个巨大的坑Hardware Manager 里 Program Device 走的是 JTAG 通道所以不管启动模式引脚是什么它都能往 FPGA 里灌 bit 流。但如果你断一次电FPGA 重新上电启动模式引脚就会把芯片引向 SPI 或者 SD 模式。如果那个模式下没有任何有效配置数据芯片就一直在那里傻等表现为“启动失败”。简单说JTAG 能绕过启动模式直接配置芯片但上电自动启动绕不过启动模式引脚。3.2 三个现场高频场景每一个我都实际踩过场景一Zynq 板卡 BOOT_MODE 拨到了 QSPIFlash 里是空的。现象是JTAG 能连上PL 的 bit 流也能通过 Program Device 灌进去DONE 瞬间亮了但只要你一断电重启所有现象全部恢复原样板子依旧不工作。很多人的第一反应是“固化步骤出错了”其实固化没错错的是拨码开关。Zynq 上电后 BootROM 会按 BOOT_MODE 决定从哪启动如果选了 QSPI而 QSPI 里没有 FSBLBootROM 就卡死了PS 不启动PL 也不会被自动配置。场景二Artix-7 板卡 M[2:0] 被默认电阻拉到 SPI 模式SPI Flash 为空。此时你上电后立刻用 JTAG 去编程会遇到一个比场景一更隐蔽的现象——Device 能识别但 Program Device 偶尔失败偶尔成功。原因是 FPGA 上电后先进入了主 SPI 配置状态一直在等 Flash 返回数据而这个等待过程还没结束你的 JTAG 指令插了进去。TAP 控制器和配置状态机在内部争抢资源结果就是行为不稳定。场景三板子上的 BOOT_MODE 引脚悬空。设计时以为“不接就是默认 JTAG”实际悬空引脚的电平可能是随机的或者被内部弱上拉拉到某个不期望的组合。调试的时候一切正常换一批板子同一批物料就偶发启动异常。这种问题用肉眼看不出来必须上电后用示波器量引脚电平。3.3 如何验证启动模式以及临时纠正的手段排查方法不复杂但需要你有意识去做首先翻开原理图找到模式引脚的连接关系。7 系列看 M[2:0] 有没有通过电阻上拉/下拉到固定电平Zynq 看 BOOT_MODE/MIO 对应的拨码开关或者电阻网络。然后用万用表或者示波器在 FPGA 上电复位完成的瞬间测一下这几个引脚的电平。注意是“瞬间”因为一部分引脚在配置完成后可能切换为普通 IO 功能比如 Zynq 的 MIO 引脚一旦进入用户模式就可能作为 PS 外设使用电平会被软件改写。所以测量时机要选在上电初期。拿到电平组合后对照芯片手册的启动模式表。以 Zynq-7000 为例BOOT_MODE[2:0] 常见组合如下具体以你要用的型号手册为准BOOT_MODE启动源备注000JTAG调试首选001QSPI板载 Flash 启动010SDSD 卡启动011NANDNAND Flash 启动如果排查发现板卡默认不是 JTAG 模式但现阶段只想验证逻辑功能最快的办法是用飞线或者改拨码开关把模式强行切到 JTAG然后重新上电。这里要注意的是改完模式引脚之后必须断电再上电让它重新采样只按一下复位是不够的。如果是你的正式固件就打算从 SPI Flash 启动那就不是切模式的问题而是要先把正确的镜像固化进 Flash。调试阶段最省心的做法是先把 BOOT_MODE 切到 JTAG 做逻辑验证验证通过后再改回 SPI 模式然后用 JTAG 或者 SD 卡把镜像烧到 Flash最后断电重启确认。提示很多量产板为了方便调试会专门设计一个 3 位拨码开关给 BOOT_MODE。如果你的板子已经画完了却没有预留这个开关那调试会非常痛苦。我的习惯是哪怕量产版要贴电阻固定模式也至少留一组测试点或者 0 欧电阻位方便后续换配置。4. 隐藏条件三上电时序和 PROGRAM_B/DONE 的握手窗口被破坏4.1 为什么 JTAG 能枚举 IDCODE配置状态机却可能没复位第三个隐藏条件比前两个更底层它直接关系到芯片内部状态机是否健康。很多人会问一个很有道理的问题如果 TAP 控制器能枚举 IDCODE说明芯片的 JTAG 域是有电的为什么还会启动失败答案是JTAG 域和配置状态机域虽然共用一部分引脚但两者的复位条件不完全一样。TAP 控制器只要 VCCAUX 电压满足要求就能工作而完整的配置启动流程依赖 POR 复位电路、电压监控、INIT_B 握手、DONE 握手这一整套流程。其中任何一环被破坏配置状态机都可能处于“看起来活着其实没就绪”的状态。最容易出问题的是上电时序。7 系列 FPGA 的上电要求一般是 VCCINT 先上电并稳定其次是 VCCBRAM、VCCAUX最后是 VCCO。如果 VCCAUX 先于 VCCINT 爬升或者 VCCO_0 明显滞后POR 电路的行为就可能不符合数据手册要求。某些情况下 POR 会提前释放配置状态机在电源还没稳定时就开始采样模式引脚采到一个错误的值后面自然起不来。更隐蔽的是“慢爬坡”。如果 VCCINT 用了软启动能力很强的 LDO并且输出电容特别大电压从 0 爬到 1.0 V 花了 200 ms而 VCCAUX 的 DC-DC 100 ms 就到位了这时 POR 逻辑的阈值比较器动作就会异常。JTAG TAP 依然可以工作因为 VCCAUX 已经稳定但配置状态机的复位释放可能提前或滞后导致后续所有动作错拍。4.2 示波器要抓哪几个点以及判断波形是否合格的依据遇到 C 类问题IDCODE 正常Program 报成功但 DONE 不亮我最推荐的手段不是打开一堆软件日志而是直接用示波器抓硬件时序。四通道示波器足够用建议这样分配通道建议节点观察目标CH1VCCINT通常是 1.0 V 或 0.85 V是否最先爬升是否有跌落CH2VCCAUX1.8 V是否在 VCCINT 之后稳定CH3VCCO_0通常 3.3 V是否最晚到位是否达到标称CH4PROGRAM_B是否在电源稳定后被释放为高电平示波器触发方式建议选正常触发触发电平设为 VCCO 的 50%时基放在 200 ms/div 到 1 s/div首先观察整个上电过程。重点看两个东西一是各电压轨的爬升顺序和时间差二是 PROGRAM_B 有没有出现异常的低电平脉冲。如果 PROGRAM_B 是直接由板上的复位芯片控制的要看它是不是在上电后保持了足够长的高电平。FPGA 规格书上一般会给出 PROGRAM_B 脉冲宽度要求比如某些 7 系列器件要求最小的低电平脉冲宽度在几百纳秒到微秒级。但更常见的故障不是程序脉冲太窄而是复位芯片在系统运行过程中周期性把 PROGRAM_B 拉低导致 FPGA 反复重启外部看到的现象就是“DONE 没稳定”。另一个要抓的信号是 DONE。配置成功时 DONE 应该从低电平跳变到高电平。如果 DONE 在 PROGRAM_B 释放后很快就变成高电平然后又掉回低电平说明内部配置流程启动后又中断了多半跟外部 Flash 或者启动模式有关。如果 DONE 从头到尾都没有跳变优先怀疑配置数据源、模式引脚或者电源时序。4.3 常见的破坏性设计以及对应的修复方向这里列几个我实际见过的问题都属于“原理图看着没问题一上电就翻车”的类型第一种DONE 引脚被外部逻辑强制拉低。DONE 是开漏输出正常需要接到 VCCO_0 并接一个上拉电阻。如果你的板子上 DONE 恰好接到了一个外部芯片的输出引脚而那颗芯片恰好输出低电平那 FPGA 就算配置成功DONE 电压也起不来。排查方法是把 DONE 上的外部连接断开或者用示波器确认 DONE 引脚到外部芯片之间有没有电平冲突。第二种PROGRAM_B 被复位芯片拉得太久。很多设计喜欢用一颗复位芯片统一控制整个板卡的复位FPGA 的 PROGRAM_B 也接在上面。但复位芯片的复位超时时间如果设置得特别长比如 500 ms而上电时序要求 PROGRAM_B 在电源稳定后必须释放否则可能错过配置窗口。建议 FPGA 的 PROGRAM_B 不要跟整个板级的复位逻辑绑在一起至少要保持独立可控。第三种电源监控芯片的上电顺序和 FPGA 要求不一致。这个问题在 Zynq 板卡上尤其常见因为 Zynq 有严格的电源时序要求。解决方向有两种一是调整电源管理芯片的配置让它按 VCCINT → VCCAUX → VCCO 的顺序输出二是如果电源芯片本身不支持顺序控制只能在硬件上增加延时电路或者使用电源时序控制器。软件再怎么调硬件时序不对都会在某个角落埋雷。5. 从 Hardware Manager 报错到示波器波形一套可复现的完整排查流程5.1 第一步先给故障归类不要直接重刷 bit 流很多人拿到板子的第一反应就是重新烧一遍 bit 流或者换一台电脑重装驱动这种操作不是不行而是效率太低。更合理的做法是先按第一节的三类故障做初步归类。如果 Open Target 都成功不了优先查 USB 枚举、驱动、物理连接和 VREF。如果 Open Target 成功但设备列表不对优先查 VREF、TCK 电气质量和扫描链配置。如果设备正常、Program 报成功但功能不工作优先查启动模式、DONE 电平和上电时序。在 Vivado Hardware Manager 里最简单的分类方法是看“目标打开之后Device 列表里的 IDCODE 是否可读”。这个操作能区分 A/B 类和 C 类。归类正确后面排查大概率不会跑偏。5.2 第二步用几条 Tcl 命令代替图形界面效率会高很多Vivado Hardware Manager 的图形界面固然清晰但很多操作用 Tcl 命令更快而且更容易复现和记录。我常用的一组诊断命令大概是这样# 打开硬件管理器对象 open_hw_manager # 连接本地硬件服务器 connect_hw_server # 打开 JTAG 目标 open_hw_target # 查看当前扫描到的所有目标 get_hw_targets # 查看目标上扫描到的所有设备 get_hw_devices # 设置当前设备用扫描到的实际设备号替换 xc7z020_1 # current_hw_device [get_hw_devices xc7z020_1] # 查询当前目标的属性观察是否有异常值 get_property PROTOCOL [current_hw_target]如果连接失败先用get_hw_targets看看硬件服务器是否枚举到了目标。如果枚举到了目标但get_hw_devices返回空或者全零重点查 VREF 和 TCK 回路。如果设备列表里出现了期望 IDCODE但后续编程失败再结合示波器查启动模式与 DONE。某些版本的 Vivado 支持通过 Tcl 设置 JTAG 频率参数如果怀疑 TCK 频率过高导致采样错误可以尝试降低频率后重新扫描。这个参数在你连接目标之前设置比较合适界面位置在 Open Target 对话框的高级设置里。很多二手板卡、杜邦线连接的目标把频率从默认值降一半甚至降一个数量级问题立刻消失。5.3 第三步一张根因判定表逐列排除我到现场调板习惯把下面的表打印出来放在示波器旁边。它基本能覆盖 90% 的 JTAG 连接和启动失败问题。现象优先怀疑验证动作修复方向Open Target 失败无目标USB 驱动 / 下载器 / VREF 全无换 USB 口、重装驱动、量 VREF修复 VREF、换下载器目标找到IDCODE 全零VREF 异常 / TCK 不稳 / 链上其它器件断电量 VREF、降低 TCK 频率重接 VREF、降频IDCODE 正确Program 超时启动模式引脚冲突 / 配置状态机未就绪确认 BOOT_MODE、看 PROGRAM_B切 JTAG 模式、复位时序Program 报成功DONE 不亮DONE 电平冲突 / Flash 无镜像 / 电源时序示波器抓 DONE、检查电平修 DONE 外部电路、固化 FlashProgram 成功功能随机异常电源纹波 / 时钟不稳 / 部分引脚冲突看电源纹波、核对引脚分配优化电源、检查硬件这张表的作用不是让你机械套用而是帮你建立一套“现象 → 假设 → 验证”的思维习惯。实际调试时往往是两三个因素叠加到一起的比如 VREF 本身就临界同时启动模式又不对两个问题一起处理才能看到效果。所以不要在一个现象上钻牛角尖按表扫一遍再交叉验证。5.4 两个真实案例复盘看懂整套流程怎么用案例一是一块 Zynq-7010 板子现象是 Hardware Manager 能认出 xc7z010Program Device 也报告成功但板级功能完全没反应PS 端没有串口输出。我按上面的流程先确认不是 A/B 类问题然后把目光放到 C 类。示波器抓 DONE发现 Program 瞬间 DONE 能拉高但断电重启后 DONE 就再也不动了。查 BOOT_MODE 拨码发现默认在 QSPI 模式而 QSPI Flash 里没有镜像。把 BOOT_MODE 切到 JTAG 模式再断电重启板子才恢复正常。这个案例说明一个简单的拨码开关状态就能让所有硬件看起来“坏了”。案例二是 Artix-7 板子现象更诡异JTAG 时好时坏偶尔识别出 IDCODE编程时随机失败有时直接报 Target connection lost。一开始怀疑下载器问题换了一根线还是不行。后来量 VREF发现它被板上一个电阻网络分压到了大概 1.2 V而 Bank 0 实际是 3.3 V。适配器按 1.2 V 的门限去驱动信号FPGA 收不到稳定的高电平。用飞线把 VREF 直接接到 3.3 V 后JTAG 链路立刻稳定。这个案例说明VREF 不匹配的表现不一定是一开始就完全不通更常见的是“间歇性神经病”。6. 调板一年后我想留给大家的几个习惯6.1 原理图阶段就给自己留好后路很多板级问题都是在原理图阶段埋下的等到贴片回来才发现就很被动。关于 JTAG 和启动我强烈建议在原理图里做这几件事JTAG 连接器的 VREF 引脚不仅要接对还要单独引出一个测试点BOOT_MODE/M 引脚不要只靠电阻焊死至少要留一组跳线或者 0 欧电阻的选择位置DONE 和 PROGRAM_B 都引出测试点方便示波器夹探头电源时序如果用的 PMIC 芯片确认配置引脚留了可编程控制。这几个改动在原理图里加起来不超过十个网络但能让你在调试阶段省下大量时间。我见过太多板子功能设计没问题就是因为没留 JTAG 调试测试点最后调板时只能拿镊子戳芯片引脚既危险又低效。6.2 现场调试的五步检查顺序到了实验室拿到一块“启动失败”的板子我建议按下面的顺序过一遍不要跳跃。第一步接好下载器后先量一下 VREF 对地电压确认它和目标 Bank 0 电压一致。这一步 30 秒就能完成能排除 20% 以上的莫名其妙连接问题。第二步确认板子当前供电状态。用万用表量 VCCINT、VCCAUX、VCCO 是否都到位如果哪一路缺失整块板子的行为都会异常JTAG 也不能幸免。第三步查启动模式引脚的电平组合。翻原理图量拨码开关或电阻网络的输出确认当前模式是 JTAG 还是其它。如果是量产板直接看默认焊接方式。第四步连上 Hardware Manager读取 IDCODE。能正确读到目标型号基本排除 VREF 全断和 TDI/TDO 链路断裂读不到或者全零回头查第三步之前的物理层。第五步结合示波器抓 PROGRAM_B 和 DONE 波形。单独用软件看信息已经不够了硬件时序才是启动成败的最终裁判。6.3 关于“三个隐藏条件”的总结性经验这三个隐藏条件我在实际项目中遇到的比例大约是启动模式问题占四成VREF 问题占三成电源时序问题占两成剩下的一成才是乱七八糟的下载器、USB 或者芯片本身损坏。所以如果你时间有限优先排查启动模式和 VREF这两项都不需要昂贵设备万用表和飞线就能搞定。最后再分享一个小技巧当你实在定位不到问题怀疑是上电时序时可以试试用实验室稳压电源手动给板子供电做一个非常缓慢的爬坡同时抓 FPGA 的 DONE 和 PROGRAM_B。如果慢上电时板子行为变好说明问题大概率就出在电源时序和 POR 上。这个办法我用过很多次虽然看起来原始但在没有高级电源分析仪的场合非常管用。