Vivado装好了、板子也接上了，打开Hardware Manager一看，就是找不到设备，折腾一晚上毫无进展。这个问题我在不同版本的Vivado、不同厂家的开发板上都遇到过，Windows和Ubuntu环境下都踩过坑。每次帮同事排查，发现大部分情况根本不是板子坏了，而是驱动、连接、权限或者线材的细节问题。这篇文章就把我实际排查过程中积累的思路完整梳理一遍，希望能让你少走弯路。
1. 问题现象全梳理：先搞清楚“无法识别”到底卡在哪一环
1.1 不同“无法识别”对应的真实原因
很多人一上来就搜“Vivado无法识别开发板”，但“无法识别”这个描述其实涵盖了完全不同的几种现象，原因和解决办法也天差地别。我建议你先花两分钟确认自己属于哪一种：
第一种，Hardware Manager界面根本没有出现设备列表，整个窗口空白，只有localhost这一行。这种情况最常见，优先怀疑驱动安装、JTAG线缆连接、板卡供电这三项。
第二种，设备列表里有未知设备，名字显示像“Unknown Device”或者一串问号，双击后报错。这种情况一般是JTAG链路上有设备但没被正确识别，问题可能出在板卡上的JTAG配置、FPGA电源状态，或者多个设备链接时的菊花链设置。
第三种，烧录时报错，但连接时正常，比如提示“Device is locked”或者“Programming failed”。这种情况虽然从广义上也算“识别有问题”，但本质是进入编程流程后才出的问题，一般和bit文件、调试器权限、Flash型号有关。
第四种，系统提示FTDI或Cable Driver安装失败，Windows下直接弹黄感叹号。这基本是驱动签名、安装顺序或者杀毒软件干扰导致的。
把现象分类的好处在于，你可以直接跳到对应的排查路径，不用从头到尾把所有操作都做一遍。我自己在这上面吃过亏，曾经因为一线材问题，把Vivado卸载重装了三遍，最后发现根本没动到点子上。
1.2 正常识别时应该看到什么样的状态
在讲排查之前，先让你知道正常状态长什么样。连接好开发板并给板上电之后，打开Vivado，在Flow Navigator左下角找到“Hardware Manager”，点击“Open Target”，然后选择“Auto Connect”。正常情况下，几秒后应该能看到设备列表里出现你的FPGA型号，比如“xc7a35t”或者“xczu9eg”，旁边会显示对应的IDCODE。如果板子上的JTAG调试器是板载的，通常还会看到一个调试器节点，例如“Digilent Adept USB Device”或者“Xilinx USB Cable”，下面挂着你的FPGA器件。
如果看到的是上述状态，说明整条链路是通的。如果只看到调试器、看不到FPGA，说明调试器与FPGA之间的JTAG链路有问题。如果什么都看不到，则按下一节的内容，从物理层开始排查。
2. 连接与供电排查：最基础也最容易被忽略的坑
2.1 线材类型和接口选择的必要性
我排查过很多“死活识别不到板子”的案例，有一小部分问题出在USB线材上。现在的开发板大多使用USB Type-C或者Micro USB接口，很多手头现有的手机充电线也能插进去，但它们很可能只是供电线，根本没有数据线芯，或者线材质量太差导致数据传输不稳定。
判断方法很简单：用同一根线连接开发板和电脑，看电脑的设备管理器或者macOS的“系统信息”里有没有出现新设备。如果完全没有反应，换一根线试试。如果换了线就有反应了，那问题就在线材上。
另外，接口也有讲究。开发板上往往有多个USB接口，有的专门用于电源输入，有的用于UART串口，有的用于JTAG调试。如果你插错了口，怎么折腾都不可能被识别。插线前看一下板子上的丝印，确认插的是标有“JTAG”“PROG”“DEBUG”字样的接口，而不是只标着“PWR”或者“UART”的口。
2.2 供电不足导致的诡异现象
供电问题是最容易和驱动问题混淆的。很多开发板通过同一个USB接口既供电又传输数据，但板载的FPGA、DDR、外围器件启动瞬间电流很大，一些笔记本电脑的USB口只能输出500mA，完全带不动整块板卡。
我遇到过一种现象：板子上的电源指示灯亮了，但是FPGA核心电压没起来，JTAG链路处于半通不通的状态，Vivado偶然能识别但一两秒后又掉线。这种问题如果不量电压几乎看不出来。
处理方式是尽量使用开发板配套的电源适配器供电，而不是依赖USB供电。如果开发板只有USB供电接口，那就插在台式机后置USB口或者带独立供电的USB Hub上，尽量别用笔记本电脑的USB口。上电后观察电源指示灯的同时，可以用万用表测量电源芯片输出端的电压值，确认是否在正确范围内。
还有一种常见情况是供电顺序问题。部分开发板要求先上电、再连接USB线缆，或者反过来。比如有些板子必须先接USB线再上电，有些则必须先上电再连USB线。具体的顺序一般在开发板手册里会写，如果没有标注，可以两种顺序都试一下，看哪种能被正常识别。
2.3 开发板拨码开关与跳线状态自检
排查完线材和供电后，还要检查板卡上的拨码开关和跳线。很多开发板设计了启动模式选择开关，用来决定是从JTAG、QSPI Flash、SD卡还是eMMC启动。当你把模式拨到了Flash启动，而Flash里的程序本身有问题时，可能在JTAG扫描阶段就会表现异常，甚至把JTAG TDI/TDO链路上的信号干扰掉。
我建议你把启动模式拨到JTAG模式再尝试连接。具体的拨码位置要看板卡的原理图或者丝印标注，常见的有“MODE”或者“BOOT”字样，旁边会有一个表格说明拨码组合对应的启动模式。这里不一定要背下来，但至少要知道“JTAG模式”对应的那一组状态。
另外，部分开发板上的JTAGE跳线帽控制是否使能板载调试器。如果跳线帽松动或者位置不对，JTAG信号根本不会送到FPGA上。重新插拔跳线帽，确保接触良好，也是一种成本极低的排查操作。
3. 驱动排查详解：Windows和Linux下的核心差异
3.1 Windows系统：Cable Drivers为何总是装不上
排除了物理层问题后，绝大多数“无法识别”都和驱动有关。Vivado本身自带的软件工具很庞大，但连接开发板时依赖的是两个底层驱动：一个是Xilinx USB Cable驱动，另一个是FTDI驱动（部分第三方调试器和开发板上使用）。
这里有个很多人都会踩的坑：安装了完整版Vivado，其实驱动已经随着安装包拷贝到本地了。但安装Vivado的时候并不会自动安装驱动，你必须手动去安装目录里找。
具体来说，在Windows下安装完Vivado后，打开设备管理器，展开“通用串行总线控制器”或者“其他设备”，看看有没有带黄色感叹号或者写着“Xilinx USB Cable”的条目。如果有，右键选择“更新驱动程序”，然后选择“浏览我的电脑以查找驱动程序”。驱动的位置一般在Vivado安装目录下的：
C:\Xilinx\Vivado\<版本号>\data\xicom\cable_drivers\nt64\dlc10_win7\这里面有一段红色的描述，大意是“该驱动未签名”或者“需要手动安装”。安装方式有两种：一是右键inf文件选择“安装”；二是在设备管理器里手动指向这个目录。如果系统提示驱动签名问题，参考下一节的说明处理。
3.2 Windows驱动签名验证：我踩过最深的坑
Windows 10和Windows 11默认强制要求驱动签名验证。早期的Xilinx Cable Drivers在部分系统上会弹出“无法验证此驱动程序软件的发布者”的提示，导致驱动装不上。虽然新版本Vivado的驱动已经有了签名，但如果你用的是老版本Vivado（比如2018.3之前的），大概率会碰到这个坑。
如果遇到签名问题，最简单的办法是进入“高级启动”模式，禁用驱动程序强制签名：按住Shift键点击“重启”，然后依次进入“疑难解答”、“高级选项”、“启动设置”，点击“重启”，重启后按数字键7或者F7，选择“禁用驱动程序强制签名”。在这个模式下安装驱动，然后正常重启。
不过这个方法只能顶一次，下次重启后签名强制又会恢复。对于老版本Vivado用户，更根本的解决方案是下载带有WHQL签名认证的驱动版本，或者干脆升级到新版本Vivado。新版本Vivado已经把驱动打包并签好名了，安装体验会好很多。
我在实际使用中还发现，部分杀毒软件和防火墙会拦截驱动安装。安装驱动时如果始终失败，可以先暂时退出杀毒软件再试一次。装好驱动后再恢复保护。
3.3 Linux系统：权限与udev规则配置
如果你在Ubuntu下使用Vivado，遇到的“识别不到开发板”通常不是驱动缺失，而是权限问题。Vivado的硬件管理器访问USB设备时，需要当前用户对设备节点有读写权限。如果/dev/ttyUSB1或者对应的USB设备节点只允许root访问，那Vivado自然无法识别。
解决方法是添加udev规则。在/etc/udev/rules.d/目录下新建一个规则文件，例如99-xilinx.rules，内容如下：
SUBSYSTEM=="usb", ATTRS{idVendor}=="03fd", MODE="0666" SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", MODE="0666"其中03fd是Xilinx的USB Vendor ID，0403是FTDI的Vendor ID。如果用的是Digilent板卡，还要加上Digilent的Vendor ID（16d0）。
保存后执行：
sudo udevadm control --reload-rules sudo udevadm trigger拔掉USB线重新插入，再打开Vivado，通常就能识别到设备了。如果你用的是非root用户登录系统，还需要确保用户加入了dialout或者plugdev组：
sudo usermod -aG dialout $USER sudo usermod -aG plugdev $USER这里要提醒一下，修改完用户组后需要重新登录才能生效。
Windows和Linux的驱动问题解决思路完全不同：Windows最怕签名和安装顺序，Linux最怕权限和不识别设备ID。在排查之前先搞清楚自己的操作系统类型，再用对应的方式处理。
4. 硬件与JTAG链路自检：排除开发板本身的问题
4.1 JTAG链路的基本概念与排查思路
如果驱动安装没有问题、供电正常、线材也没问题，但还是识别不到，那就要往板卡硬件链路方向排查了。这里必须简单说一下JTAG链路的工作原理，不然你很难理解后续的操作。
JTAG是调试接口标准，在FPGA调试场景下，总共有四根关键信号线：TDI（数据输入）、TDO（数据输出）、TCK（时钟）、TMS（状态控制）。调试器通过这四根线和FPGA通信。如果其中任何一根信号线断路、短路或者被拉死，调试器就无法和FPGA建立有效的通信，表现就是“找不到设备”。
当开发板上有多个JTAG设备（比如同时有FPGA和CPU）时，所有设备会以菊花链形式串联：调试器的TDI接到第一个设备的TDI，第一个设备的TDO接到第二个设备的TDI，以此类推，最后一个设备的TDO接回调试器。如果中间某个设备没供电、处于冻结状态或者配置异常，整条链路就断了，后面的设备全部无法识别。
4.2 用示波器和万用表快速定位链路故障
对于普通用户来说，没有示波器也能做一部分检查。先用万用表量一下TCK、TMS、TDO、TDI这几个引脚对地的阻抗，一般不要直接对地短路。如果发现某个引脚对地阻值接近0欧姆，极有可能芯片的引脚被击穿或者焊接短路。
如果有示波器，可以把探头放在TCK引脚上，然后在Vivado里点击“Open Target”。正常状态下，调试器会主动输出脉冲，TCK引脚上应该能看到方波。如果TCK有波形但TDO没有响应，说明调试器到FPGA的链路在前半段是通的，问题出在FPGA本身没有正常启动或者休眠。
还有一种情况是板子上有多个JTAG设备，其中一个处于未知状态把TDI/TDO拉死。这时可以把链路上其他的设备单独断电或者断开，只保留FPGA再测试。比如某些SoC开发板上有ARM处理器和FPGA两个JTAG设备，可以尝试断开其中一个的供电跳线，看能否单独识别到另一个。
4.3 使用Vivado自带的硬件自检功能
Vivado的Hardware Manager本身提供了一些辅助排查功能。当你打开Hardware Manager后，在窗口上部的连接按钮旁边，有一个“Open Target”下拉菜单，里面除了“Auto Connect”，还有“Open Recent Target”和“Open New Target”。如果设备列表为空，可以尝试手动指定连接参数。
在“Open New Target”的向导中，有一个选项是选择连接类型，比如“Local server”或者“Remote server”。如果采用远程连接方式，要注意主机名和端口配置。对于一些特殊调试器，这里还可以指定调试器的连接参数。
另外，Vivado支持命令行方式扫描JTAG链。打开Vivado的Tcl Console，输入：
scan_jtag_hw_devices如果返回的列表为空，说明Vivado底层没有发现任何JTAG设备。这时候驱动和物理链路至少有一项存在问题。如果返回了设备IDCODE，但Hardware Manager里依然识别不到，可能是Vivado的器件支持文件问题，可以考虑升级版本或者安装对应器件的补丁包。
这个命令对于判断问题出在“Vivado层”还是“系统层”非常有用。如果系统层能看到设备节点、但Tcl扫描不到，优先怀疑驱动类型不对或者驱动被占用。
5. Linux环境下的特殊场景：挂载开发板与权限联动问题
5.1 “开发板挂载Ubuntu”到底指什么
搜索热词里有一个“开发板挂载ubuntu”，这句话在不同的语境下意思完全不同。有一种情况是开发板上的文件系统通过USB或网络挂载到Ubuntu主机上，用于传输文件。另一种情况是在Ubuntu主机上连接开发板并显示为可移动存储设备，但开发板本身没有正常进入系统。
如果你是在做嵌入式开发时遇到“开发板挂载Ubuntu”后无法使用Vivado调试的情况，大概率是因为开发板以USB Mass Storage模式被识别成U盘了，占用了USB接口资源或者改变了USB设备的模式。解决办法是卸载挂载文件系统，然后让USB设备回到JTAG/调试模式。
还有一个常见场景是开发板跑Linux系统，通过USB线连接Ubuntu主机，希望在主机侧看到串口设备节点，同时用Vivado做调试。这时可能出现串口节点被ModemManager等系统服务占用的情况。ModemManager会把串口设备误认为是调制解调器，不断发AT指令去探测，导致串口被塞满，Vivado连接时卡住。
解决方法有两种：一种是禁用ModemManager服务，执行：
sudo systemctl disable --now ModemManager另一种是配置udev规则，让特定的USB设备跳过ModemManager的检测。两种方法我都用过，在Ubuntu 20.04和22.04上都能解决串口被占的问题。
5.2 虚拟机USB直通导致识别失败的排查要点
如果你使用的是Windows宿主机+Linux虚拟机，或者反过来Linux宿主机+Windows虚拟机，那么USB透传配置问题也可能导致Vivado识别不到开发板。VirtualBox和VMware都支持USB设备直通，但启用直通之前，必须在虚拟机设置里开启USB控制器，并且安装增强功能或者VMware Tools。
我曾经遇到过一个情况：虚拟机能识别到FTDI芯片，但Vivado在虚拟机里始终打不开设备。后来发现是USB 3.0控制器和USB 2.0控制器的直通策略不一致。解决办法是先用USB 2.0模式直通，确认能识别后再切换USB 3.0模式测试。
另外，如果你在Linux宿主机上跑Windows虚拟机，还要注意宿主机的udev权限不会拦截设备的释放。宿主机上某个进程使用了这个USB设备，虚拟机就拿不到完全的控制权，表现出来就是“设备在列表里但打不开”。
5.3 多开发板同时连接时的设备分配冲突
如果你同时插着多个开发板或者调试器，Vivado默认会列出所有JTAG链。但某些情况下，多个USB设备会抢占同一个串口设备节点，或者Linux的USB设备编号不稳定，导致Vivado记住了旧的设备路径却找不到新设备。
解决方法是每次插入开发板后，使用dmesg命令查看系统为它分配的设备节点：
dmesg | tail -n 20重点看有没有“FTDI USB Serial Device converter now attached to ttyUSB0”之类的输出。如果你确认设备节点变了，那就需要手动删除旧的udev规则或者调整符号链接策略，让设备路径保持稳定。
多个开发板同时使用时，建议为每个开发板创建独立的udev规则，通过硬件序列号或者物理端口位置分配固定名称。这样Vivado每次都能找到对应的设备，不会出现插拔顺序改变后设备路径漂移的问题。
6. 常见问题与排查技巧实录
6.1 问题速查表
我把实际排查过程中遇到频率最高的十种情况整理成表格，方便你对号入座。这张表不是从文档里抄的，每条都是我自己验证过的结论。
| 问题现象 | 优先排查方向 | 关键操作 |
|---|---|---|
| Hardware Manager空白无设备 | USB线材/JTAG接口选择 | 换线、换接口、确认供电 |
| 设备列表有Unknown Device | 驱动/供电顺序 | 手动装驱动、调整上电时序 |
| Windows下驱动黄色感叹号 | 驱动签名/安装路径错误 | 禁用签名强制、手动指定目录 |
| Linux下设备不可访问 | udev权限/用户组 | 添加规则并重载、加入dialout组 |
| 串口被系统服务占用 | ModemManager | 禁用ModemManager服务 |
| 识别到调试器但找不到FPGA | JTAG链路/启动模式 | 拨码开关切换、检查TDO信号 |
| 烧录时报Device is locked | 目标芯片被占用 | 检查是否同时打开两个Hardware Manager |
| USB设备插入后无任何反应 | 线材/供电能力不足 | 换数据线、使用独立电源 |
| 虚拟机里无法识别 | USB直通未配置 | 开启USB控制器、安装增强工具 |
| Auto Connect卡死无响应 | USB控制器驱动冲突 | 重启电脑、换USB口、关闭快速启动 |
这张表可以当做一个快速索引。遇到问题先对照现象找到对应行，再按优先级逐项排查。
6.2 独家避坑技巧：为什么重装Vivado解决不了问题
很多人遇到识别问题后的第一反应是重装Vivado，但实际上重装解决不了驱动和权限问题，因为Vivado的安装过程本身不会清理旧的驱动和权限配置。尤其是我见过很多人卸载Vivado时残留了大量文件，导致重装后引入了更多异常。
正确的做法是，在重装Vivado之前先把原来的驱动彻底清理：卸载Vivado之后，在设备管理器里卸载所有的Xilinx和FTDI相关设备，并勾选“删除此设备的驱动程序软件”，同时删除C:\Program Files\Xilinx\Vivado<版本号>\data\xicom\cable_drivers目录下残留的旧驱动。然后再重新安装Vivado，并在安装后手动安装驱动。
如果你要彻底清理注册表里的驱动残留，可以用以下命令在管理员权限的CMD中执行：
sc query | findstr /i "xilinx ftdi"然后停止并删除对应的系统服务。注意删除系统服务要非常谨慎，建议在操作前先备份注册表，不要乱删自己不确定的服务。
6.3 日志与报错信息：如何准确读取关键线索
最后分享一个非常实用的技巧：Vivado的硬件管理器其实会把详细的连接日志输出到Tcl Console和日志文件中。很多报错看起来吓人，但日志里会明确告诉你失败原因。
当连接失败时，打开Vivado安装目录下的：
<安装目录>\Vivado\<版本号>\data\xicom\*.log或者查看当前工程的run目录下生成的hw.log文件。里面有类似这样的输出：
INFO [Common 17-208] Attempting to launch hw_server.... ERROR [Labtools 27-2253] No hardware device is connected.第一行说明启动硬件服务器时没有找到设备，需要检查系统层面；第二行说明Vivado启动正常但没有设备连接，需要检查驱动和硬件链路。
还有一类报错很值得留意：
ERROR [Labtools 27-2264] Hardware device is locked.这种问题通常是因为有另一个进程（比如另一个打开的Vivado工程，或者旧版的hw_server）占用了调试器。解决方法是打开任务管理器，找到hw_server进程并结束它，然后重新连接。
另外，如果你的Vivado版本较新，在Hardware Manager窗口左下角有“Hardware Servers”窗口，里面可以看到硬件服务器的日志输出和连接状态。如果你用的是远程硬件服务器（比如远程连接到另一台电脑上的hw_server），要确认远程主机的防火墙放行了3121端口，否则也会出现“找不到设备”的假象。
7. 实操过程：从插线到识别成功的完整演练
7.1 场景复现：全新安装Vivado后的首次连接
假定你的环境是Windows 11，安装了Vivado 2023.1，手头有一块基于Artix-7的开发板，找不到驱动也识别不到设备。我会按照下面的顺序完整操作一遍，你在自己机器上照做即可。
第一步，把USB线连接到开发板的JTAG调试口，另一端连接到电脑的USB口。如果开发板有独立电源，接上电源并开机。检查板载电源指示灯是否正常点亮。
第二步，打开设备管理器。如果看到设备管理器里其他设备一栏有“Xilinx USB Cable”或者带感叹号的未知设备，右键点击它，选择“更新驱动程序”。
第三步，选择“浏览我的电脑以查找驱动程序”，然后浏览到Vivado的驱动目录。对Vivado 2023.1来说，默认路径是：
C:\Xilinx\Vivado\2023.1\data\xicom\cable_drivers\nt64\dlc10_win7\选中该目录后点击下一步，Windows会提示安装一个未签名的驱动，确认安装即可。
第四步，打开Vivado，在Flow Navigator点击“Open Hardware Manager”，然后在“Open Target”菜单中选择“Auto Connect”。观察底部Tcl Console输出。正常情况下，你会看到类似：
INFO [Labtools 27-2285] Successfully connected to the target设备列表中出现xc7a35t等型号。
这四步操作其实只花五分钟，但我见过很多人卡在第三步找不到驱动目录。实际上Vivado安装后驱动目录就存在了，只是Windows的驱动更新向导默认不会自动搜索这个路径。
7.2 场景复现：Linux下Vivado找不到调试器
假设你的环境是Ubuntu 22.04 LTS，Vivado 2022.2，插入板卡后执行dmesg确认系统识别到了FTDI设备，但Vivado的Hardware Manager显示空白。
第一步，先确认USB设备的Vendor ID：
lsusb输出中应该能看到“Future Technology Devices International, Ltd FTDI FT2232C/Dual USB UART/FIFO”这一类设备，前面的ID号如果是0403:6010，说明FTDI芯片已经正常初始化。
第二步，创建udev规则：
sudo touch /etc/udev/rules.d/99-xilinx.rules echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", MODE="0666"' | sudo tee /etc/udev/rules.d/99-xilinx.rules sudo udevadm control --reload-rules sudo udevadm trigger第三步，把当前用户加入dialout组：
sudo usermod -aG dialout $USER sudo usermod -aG plugdev $USER第四步，注销重新登录（或者重启系统），重新插拔USB线缆，再打开Vivado连接。此时基本能够识别到设备。如果还不行，用Tcl命令自查：
scan_jtag_hw_devices如果扫描结果仍然是0，说明问题在设备驱动层面，尝试安装libusb相关的依赖：
sudo apt install libusb-1.0-0-dev7.3 调试器和线缆选型建议
如果你手头的开发板板载调试器质量较差，或者你自己买了一个独立的Xilinx Platform Cable USB II，那么线缆选型也会影响识别成功率。Xilinx官方推荐的线缆型号很多，但实际使用中，同级别的第三方线缆在性价比上确实有明显优势。
在选择USB线时，建议优先选线径较粗、长度较短（不超过一米）的线。长度越长的USB线衰减越严重，高频信号的质量会下降，导致JTAG时序不稳定。如果你家里只有一根三米的充电线，我建议你去买一根短的数据线再试，很可能问题瞬间解决。
另外，关于调试器的供电。部分独立的JTAG调试器需要额外的供电才能稳定驱动JTAG信号。如果你的调试器上有外部电源接口，并且板卡的JTAG接口本身不带供电，那么插上外部电源通常是必要的。不要指望USB口那500mA电流能同时供调试器和板载电路稳定工作。
7.4 连接成功后建议立即做的一件事
当你终于成功识别到开发板，我建议你立刻做一次IDCODE验证：在Hardware Manager里右键点击设备节点，选择“Get Device Properties”，查看IDCODE。把这个值记录下来，以后遇到“设备识别异常”时，先对比IDCODE是否一致。如果IDCODE和正常值不一致，说明FPGA的IDCODE配置有异常，很可能是配置引脚电平不对或者芯片有问题。
同时，建议你把这套完整环境备份下来，尤其是Windows下的驱动安装路径和Linux下的udev规则。下次重装系统或者换电脑时，直接照做，不用再踩一遍坑。我自己就是把这些命令和路径专门记在了一个文档里，每次环境变更都能快速复现，省了很多时间。
8. 最后的几点经验补充
连接开发板这件事，很多时间其实花在了排除各种环境因素上。我最后再分享几条个人体会：
第一，不要迷信最新版Vivado。某些新版本的Vivado刚发布时，对特定系列开发板的支持反而不如前一个版本稳定。如果你使用的是老款开发板，遇到识别问题时可以尝试退回一个版本，这比在网上搜索各种奇怪的补丁有效得多。
第二，硬件调试器的驱动和用户软件是两套独立体系。换电脑后即使重装Vivado，也不一定意味着驱动会自动更新。我养成的习惯是每到一个新环境，第一件事就是手动去驱动目录里确认一次驱动是否能正常安装，而不是等Vivado报错才去处理。
第三，板卡之间的差异很大。同一品牌的不同型号开发板，JTAG接口定义和默认跳线状态可能完全不一样。网上搜到的教程未必适用于你的开发板，看板卡自带的原理图和用户手册才是最稳妥的。如果你找不到手册，至少拿万用表和放大镜看清楚板子上的丝印标注再动手。
识别开发板这个问题虽然烦人，但基本没有真正解决不了的硬伤。按照从物理层到系统层再到应用层的顺序排查，大多数问题都能在半小时内解决。希望这篇记录能帮你少走一些弯路。
