Vitis 烧录 FPGA 失败排查：底层配置与硬件连接详解

ls -l /dev/bus/usb/** | grep -i "03fd\|0403"

你应该能看到相关设备节点的权限变成了 crw-rw-rw- ，并且属于 dialout 组。

💡 小贴士 ：如果不确定自己的 JTAG 设备 ID，插拔前后各跑一次 lsusb ，对比新增项即可定位。

二、JTAG 链断了？可能是物理连接或模式设置不对

即使权限搞定了，还可能遇到'设备不在链上'（Device not found in chain）这种提示。这时候就要检查 JTAG 链本身的通路是否完整 。

JTAG 是怎么工作的？

JTAG 是一种标准边界扫描协议，依靠四根核心信号线工作：

• TCK ：时钟，驱动状态机；
• TMS ：模式选择，控制状态跳转；
• TDI ：数据输入；
• TDO ：数据输出（反馈通道）；

多个芯片可以串联成一条链，主机依次发送指令进行测试或编程。FPGA 厂商会在每个器件内部集成一个唯一的 IDCODE （32 位），用于身份识别。

当 Vitis 尝试连接时，实际上是通过 hw_server 向 JTAG 链发查询命令，等待目标返回 IDCODE。如果收不到响应，就会判定为'无设备'。

常见故障点有哪些？

快速诊断：用 XSDB 命令行试试看

打开 Vitis 自带的 Xilinx Script Debugger (XSDB) ，输入以下命令：

connect targets

正常情况下你会看到类似这样的输出：

Available Targets: 1 xczu7ev_1 2 pl 3 psu

如果返回空列表，或者提示'connection failed'，那就说明 JTAG 链层面出了问题。

⚠️ 特别注意：Zynq/Zynq UltraScale+ 系列中，PL 侧的 JTAG 访问有时依赖 PS 侧先启动。某些板子需要先烧录 FSBL 或运行 BOOT.BIN 才能激活 JTAG 路径。如果你的板子是 SD 卡启动模式，请确保至少能完成一级引导。

三、供电不稳？FPGA 正在'饿肚子'编程

你以为只有软件和协议重要？其实 电源才是最容易被忽视的关键环节 。

FPGA 在配置阶段非常'吃电'。以 Kintex-7 为例，其配置期间的核心电压（VCCINT）瞬态电流可达 1.5A 以上 ，远高于静态功耗。如果你用的是 USB 供电的小型开发板，或者电源模块带载能力不足，很容易导致电压跌落，进而引发配置失败。

典型症状包括：

• 编程中途突然中断
• CRC 校验失败
• FPGA 反复重启
• 板载 LED 闪烁异常

这些都不是软件 bug，而是典型的 电源完整性问题 。

如何判断是不是供电惹的祸？

最简单的方法： 拿个万用表，测一下 VCCINT、VCCAUX、VCCO 这几个关键电源轨的电压波动情况 。

理想状态下，它们应在标称值±5% 以内（例如 1.0V ±50mV）。如果发现电压在配置瞬间明显下跌（比如掉到 0.9V 以下），基本就可以确定是电源拖了后腿。

工程师实战建议：

1. 优先使用外接稳压电源 ，而不是依赖 PC 的 USB 口供电；
2. 加装去耦电容 ：靠近 FPGA 的电源引脚并联 0.1μF 陶瓷电容 + 10μF 钽电容，吸收高频噪声；
3. 避免长导线供电 ：电阻会导致压降，尤其是大电流场景；
4. 检查上电顺序 ：部分高端 FPGA（如 UltraScale+）要求多电源按特定顺序上电，否则会锁死。

📌 真实案例 ：有位同事调试 Artix-7 时总出现随机配置失败，换了三次线缆都没解决。最后发现是用了劣质 USB HUB 供电，内阻太大导致电压不稳定。换上独立 5V/3A 电源后问题消失。

四、hw_server 罢工了？它是 Vitis 和硬件之间的'翻译官'

很多人不知道，当你在 Vitis 里点'Program Device'的那一刻，背后真正干活的是一个叫 hw_server 的后台服务程序。

你可以把它理解为一个'硬件代理'：Vitis 负责图形化操作和流程控制，而具体怎么跟 JTAG 通信、怎么下发比特流，则全部交给 hw_server 处理。

它是怎么工作的？

[Vitis IDE] ↓ (TCP, localhost:3121) [hw_server] ↓ (libusb → USB → JTAG Adapter) [FPGA Board]

默认情况下，Vitis 会自动拉起 hw_server 。但如果端口被占用、服务崩溃或权限不足，这个桥梁就断了。

常见问题及应对策略

❌ 现象 1： hw_server 启动失败

查看日志文件：

cat ~/.Xilinx/hw_server.log

常见错误：

• libusb_open failed: Permission denied → 回头检查 udev 规则
• Address already in use → 3121 端口被占用，可用：

lsof -i :3121
kill -9 <pid>

✅ 手动启动服务（推荐调试时使用）

/opt/Xilinx/Vitis/2023.2/bin/hw_server --allow-remote-clients &

💡 添加 --allow-remote-clients 参数后，其他机器也可以通过网络连接该服务器，适合远程调试或自动化部署。

🔄 连接远程服务器（跨机烧录）

在 XSDB 中使用：

connect -host 192.168.1.100 -port 3121

🔒 注意：防火墙需放行 3121 端口，否则会被拦截。

实战排错流程图：快速定位你的问题

遇到烧录失败，不要慌，按照下面这张逻辑走一遍，基本都能找到根源：

开始
↓
点击 Program Device 失败？
↓ 是
查看是否有 "No hardware targets" 提示？
↓ 是
→ 检查 udev 规则 & USB 权限
→ 修复后重试
↓ 否
能否在 XSDB 中执行 connect && targets 成功？
↓ 否
→ 检查 JTAG 物理连接、供电、TCK 频率
→ 修复
↓ 是
烧录过程中超时或 CRC 错误？
↓ 是
→ 降低 JTAG Clock（设为 1MHz）、更换优质线缆
↓ 否
检查 hw_server 是否响应？日志有无 libusb 错误？
↓ 是
→ 重启服务、关闭冲突工具
↓ 否
→ 可能是比特流文件问题，检查生成过程
↓ 成功！

总结：底层配置决定开发效率

我们常说'工欲善其事，必先利其器'，但在 FPGA 开发中，'器'不只是 Vitis、Vivado 这些工具本身，还包括整个软硬件协同环境的健壮性。

一次成功的烧录，背后是 权限管理、物理连接、电源设计、服务架构 等多个环节精密配合的结果。任何一个环节松动，都会导致整个流程瘫痪。

掌握这些底层知识的意义不仅在于'解决问题'，更在于 建立系统级思维 。未来当你面对 Versal ACAP、多 FPGA 同步、远程产线烧录等复杂场景时，今天的这些经验将成为你从容应对的基础。

所以，下次再遇到'Vitis 装好了却烧不进 FPGA'，别急着百度重装教程。静下心来，从这四个维度逐一排查，你会发现：原来最难搞的，从来都不是软件，而是那些你以为'应该没问题'的细节。