1. 项目概述为什么ZYNQ的QSPI FLASH烧写不是“点几下鼠标”就能搞定的事ZYNQ、QSPI、FLASH、MultiBoot——这四个词凑在一起对刚从纯FPGA或纯ARM开发转过来的工程师来说就像第一次看到电路板上密密麻麻的BGA焊点一样表面平静底下全是暗流。我带过三届校招新人几乎所有人第一次尝试用Vivado SDK或Vitis烧写QSPI FLASH时都卡在同一个地方烧进去的bitstream能跑但重启后黑屏或者MultiBoot切换失败系统死在PL配置阶段更常见的是串口打印出一串“WARNING: Failed to communicate with the flash chip”然后就再没下文了。这不是工具链的问题也不是硬件坏了而是ZYNQ这个异构平台把“烧写”这件事彻底重构了——它不再是往一块存储器里灌数据而是一场跨PSProcessing System与PLProgrammable Logic边界的协同作战。核心难点在于QSPI FLASH在ZYNQ里承担三重角色——它既是PS端ARM的启动介质存放FSBL、U-Boot、Linux kernel又是PL端FPGA逻辑的配置源存放bitstream还是用户应用数据的持久化载体如参数、日志。MultiBoot则进一步把这种耦合推向极致你得在同一块FLASH里按严格顺序排布多个bitstream镜像并让FSBL在启动时根据GPIO状态或寄存器值动态选择加载哪一个。一旦地址偏移算错1个字节、擦除粒度选错、或FSBL的boot image header没对齐整个系统就会卡在“Configuration Logic Stuck”状态连JTAG都救不回来。网上那些“zynq烧写教程”大多只教你怎么点开Vivado的Program Flash窗口却没人告诉你那个“Flash Type”下拉菜单里选“qspi_single”还是“qspi_dual_parallel”直接决定你后续能否支持MultiBoot那个“Offset Address”填0x00100000还是0x00200000背后是QSPI控制器的地址映射规则和Xilinx官方推荐的分区方案而“error: flash download failed - target dll has been cancelled”这种报错90%的情况根本不是DLL问题而是QSPI引脚复位时序没满足芯片手册里那行不起眼的“tRES1 ≥ 100ns”。这篇文章不讲理论推导也不堆砌API函数。我会带你从一块裸ZYNQ-7020开发板开始实打实地完成一次MultiBoot镜像的生成、烧写、验证和故障排查。所有步骤基于Xilinx官方文档UG583Zynq-7000 SoC TRM和UG1083Vivado Design Suite User Guide: Programming and Debugging但会把那些藏在PDF第327页的注释、附录里的表格、以及论坛里老工程师们用血泪换来的经验全部摊开来讲清楚。适合正在做ZYNQ项目、手头有开发板、需要快速落地MultiBoot功能的嵌入式/FPGA工程师也适合被“flash download failed”折磨到凌晨三点、急需一份可执行方案的应届生。你不需要精通ARM汇编但得知道什么是FSBL、bitstream、BIN文件你不需要会写Verilog但得理解QSPI总线的基本读写时序。接下来的内容每一行命令、每一个参数、每一张表格都是我在三个不同客户项目中反复验证过的。2. MultiBoot架构设计与QSPI FLASH分区逻辑拆解2.1 ZYNQ启动流程中的QSPI角色不只是“存储器”更是“启动调度器”ZYNQ的启动过程远比传统MCU复杂。当上电复位后PS端的ROM Bootloader固化在芯片内部首先接管控制权它会根据BOOT_MODE引脚状态决定从哪个设备加载第一段代码。当选择QSPI模式时ROM Bootloader会从QSPI FLASH的固定地址通常是0x00000000开始连续读取256字节的Header数据。这个Header不是用户随便写的而是Xilinx定义的Boot Image Header它包含关键信息镜像长度、加载地址、执行地址、校验和、以及最重要的——Image Type字段0x01FSBL, 0x03Bitstream, 0x05Application。ROM Bootloader只认这个Header如果格式不对或校验失败它会直接跳过该镜像继续往后找下一个Header。这就是MultiBoot的底层基础多个镜像在FLASH里首尾相接每个镜像前都有自己的HeaderROM Bootloader像一个不知疲倦的快递分拣员挨个检查包裹单Header只把标着“FSBL”的包裹交给PS处理把标着“Bitstream”的包裹交给PL配置引擎。但问题来了ROM Bootloader本身不支持“选择性加载”。它只会从头开始找到第一个有效的FSBL镜像就执行。那MultiBoot怎么实现“按需切换”答案是FSBL的二次调度。Xilinx提供的FSBL源码位于SDK_Install/data/embeddedsw/ThirdParty/sw_services/fsbl/src/里有一段关键逻辑在成功加载并执行完自身后FSBL会去读取特定GPIO引脚的状态比如MIO[10]或者查询某个寄存器如slcr.A9_CPU_RST_CTRL然后根据这个值计算出下一个要加载的bitstream在FLASH中的起始地址。这个地址不是硬编码的而是通过FSBL工程里配置的Boot Image Table来管理的。所以真正的MultiBoot决策点不在ROM Bootloader而在FSBL。这也是为什么很多初学者烧写失败——他们只烧写了bitstream却忘了FSBL必须是“MultiBoot-aware”的版本且其源码里GPIO检测逻辑必须与硬件设计匹配。2.2 QSPI FLASH物理分区地址空间如何被切分成“启动区”、“逻辑区”和“数据区”一块典型的128Mbit16MBQSPI FLASH在ZYNQ MultiBoot场景下绝不能简单地当成一个大硬盘来用。Xilinx官方强烈推荐采用分层分区策略这是避免地址冲突、擦除误操作和启动失败的铁律。我们以最常见的Winbond W25Q128JV为例实际项目中请务必核对你的FLASH型号Datasheet其扇区Sector大小为4KB块Block大小为64KB。分区方案如下表所示分区名称起始地址结束地址大小用途关键约束Boot Header区0x000000000x000000FF256B存放Primary FSBL的Header必须与ROM Bootloader读取位置严格对齐Primary FSBL区0x000001000x0001FFFF128KB存放主FSBL二进制需预留足够空间FSBL编译后通常80-110KBBoot Image Table区0x000200000x00020FFF4KB存放MultiBoot镜像索引表地址固定FSBL硬编码读取Bitstream 0区0x000210000x0011FFFF1MB第一个FPGA逻辑镜像必须4KB对齐大小由bitstream决定Bitstream 1区0x001200000x0021FFFF1MB第二个FPGA逻辑镜像同上与BS0间隔至少1个扇区U-Boot区0x002200000x002DFFFF768KB存放U-Boot二进制通常600-700KB需留余量Linux Kernel区0x002E00000x005DFFFF3MB存放zImage或uImage压缩内核约2.5MB解压后更大RootFS区0x005E00000x00FFFFFF~9.5MB存放initramfs或jffs2文件系统根据实际需求调整这个分区表不是拍脑袋定的。关键约束来自三个方面第一QSPI控制器的地址映射。ZYNQ PS端QSPI控制器QSPI0的AXI地址空间默认映射到0xFC000000但通过修改SLCR寄存器可以将其重映射到0x00000000即FLASH物理地址直连这是Vivado SDK烧写工具工作的前提第二擦除操作的粒度。QSPI FLASH最小擦除单位是扇区4KB如果你把两个bitstream紧挨着放擦除BS0时会连带擦掉BS1的Header导致MultiBoot失效。因此每个bitstream区前后必须留出至少一个空扇区作为隔离带第三FSBL的硬编码寻址。FSBL源码里读取Boot Image Table的地址是写死的0x00020000这个值在FSBL工程配置时无法更改必须严格遵守。我曾在一个项目中因为把Table区挪到0x00030000导致FSBL永远读不到镜像列表调试了两天才发现是这个硬编码坑。2.3 MultiBoot镜像生成的核心机制Bin文件、Header与Image Table的三位一体MultiBoot的镜像不是简单地把几个.bit文件拼在一起。Xilinx提供了一套完整的镜像打包工具——bootgen它负责将FSBL、bitstream、application等二进制文件按照严格的格式要求组装成最终烧写到FLASH的.bin文件。这个过程有三个不可替代的环节第一Bin文件生成。.bit文件是Vivado综合实现后生成的原始FPGA配置数据但它不能直接烧写。必须先用promgen或Vivado的“Generate Bitstream”选项将其转换为.bin格式。.bin是纯二进制流没有Header也没有校验。关键参数是-o指定输出名-w指定宽度对于QSPI single mode用-w 1dual parallel mode用-w 2-p指定目标器件如-p xc7z020clg400-1。很多人忽略-w参数结果烧写后PL配置失败因为QSPI控制器读取的数据宽度与FLASH实际输出不匹配。第二Header注入。bootgen工具的核心任务就是为每个.bin文件生成并注入标准的Boot Image Header。Header结构固定为256字节其中最关键的是Image LengthOffset 0x08-0x0B整个镜像含Header的字节数必须精确计算Load AddressOffset 0x10-0x13该镜像加载到OCM或DDR的地址FSBL会据此搬运数据Execution AddressOffset 0x14-0x17镜像执行入口地址FSBL或Application的起始PCImage TypeOffset 0x200x01FSBL, 0x03Bitstream, 0x05ApplicationPartition AttributesOffset 0x24Bit 0Checksum Enable, Bit 1Auto Start, Bit 2MultiBoot。bootgen会自动填充这些字段但前提是你的BIFBoot Image Format文件描述正确。BIF是一个文本文件定义了镜像的组成和顺序。例如一个支持MultiBoot的BIF文件片段the_ROM_image: { [bootloader] fsbl.elf [address0x00021000, typebitstream] system_wrapper.bit [address0x00120000, typebitstream] system_wrapper_backup.bit [offset0x00020000] bootimage_table.bin }注意[address...]指定了每个bitstream在FLASH中的绝对地址这必须与前面的分区表完全一致[offset...]指定了Boot Image Table的位置这个值是FSBL硬编码读取的绝不能错。第三Image Table构建。Boot Image Table是一个简单的二进制数组每个条目8字节包含Image Address4B、Image Size4B。FSBL在启动时会从0x00020000地址读取这个表然后根据GPIO状态比如MIO[10]为高电平选择加载Table中第1个条目BS0或第2个条目BS1对应的bitstream。Table的生成通常用一个小脚本完成例如Python# gen_table.py import struct table_data [ (0x00021000, 0x000FF000), # BS0: addr, size (0x00120000, 0x000FF000), # BS1: addr, size ] with open(bootimage_table.bin, wb) as f: for addr, size in table_data: f.write(struct.pack(II, addr, size))这里II表示小端序的两个32位整数与ZYNQ ARM的字节序一致。如果Table生成错误FSBL会加载一个不存在的地址后果就是PL配置超时系统卡死。3. 实操全流程从Vivado工程到QSPI FLASH烧写验证3.1 Vivado工程准备PS配置、PL逻辑与FSBL定制的三步闭环MultiBoot的根基在Vivado工程里。任何一步配置失误都会导致后续烧写功亏一篑。我建议采用“自顶向下”的验证策略先确保单镜像能稳定启动再叠加MultiBoot。第一步PS端基础配置。在Vivado Block Design中双击ZYNQ7 Processing System IP打开Re-customize窗口。关键设置有三处Clock Configuration确保FCLK_CLK0通常用于PL逻辑时钟频率设置合理比如100MHz。这个时钟会驱动QSPI控制器频率过低会导致通信超时Peripheral I/O Pins在MIO Configuration标签页找到QSPI外设勾选QSPI并确认QSPI0的引脚分配如MIO[1..6]与原理图一致。特别注意QSPI_FBCLK反馈时钟引脚它必须连接到FLASH的/IO3引脚否则Dual Parallel模式无法工作Advanced Peripheral Configuration展开QSPI将QSPI Mode设为Single或Dual Parallel。这里的选择决定了后续bootgen的-w参数和FLASH的接线方式。Dual Parallel模式速度翻倍但需要额外的IO引脚且FLASH必须支持此模式W25Q128JV支持。第二步PL逻辑设计与约束。无论你的PL逻辑多么复杂必须保证其bitstream能被正确加载。关键约束是Reset信号同步PL逻辑的全局复位sys_rst必须由PS端的pl_resetn驱动且经过两级同步器两级FF后再接入逻辑。否则PS启动完成前PL就开始运行会导致未初始化的寄存器产生亚稳态时钟域交叉如果PL逻辑使用了多个时钟如AXI总线时钟和ADC采样时钟必须在跨时钟域路径上添加async_reg属性或使用Xilinx官方的CDCIP核。我曾遇到一个案例ADC数据总线跨时钟域未处理烧写后系统偶尔死机现象是warning: failed to communicate with the flash chip其实是PL逻辑异常干扰了QSPI总线IO标准与电压QSPI FLASH的IO标准通常是LVCMOS18而ZYNQ MIO的默认标准是LVCMOS33。必须在XDC约束文件中为QSPI引脚明确指定set_property IOSTANDARD LVCMOS18 [get_ports {qspi_io[0]}] set_property IOSTANDARD LVCMOS18 [get_ports {qspi_io[1]}] ...第三步FSBL工程定制与MultiBoot使能。在Vivado中生成比特流后右键点击Generate Bitstream选择Launch SDK。在SDK/Vitis中创建一个新的Application Project类型选Zynq FSBL。这是最关键的一步在FSBL工程的src目录下找到fsbl_debug.h将#define DEBUG_PRINT取消注释以便后续串口调试打开fsbl_main.c定位到FsblHookBeforeBitstreamDload()函数。这是FSBL加载bitstream前的钩子函数MultiBoot的GPIO检测逻辑就写在这里。示例代码u32 FsblHookBeforeBitstreamDload(void) { u32 Status; u32 GpioValue; // 读取MIO[10]状态高电平选BS1低电平选BS0 GpioValue XGpioPs_ReadPin(GpioInstance, 10); if (GpioValue 1) { // 加载BS1修改bitstream地址 FsblInstance.ImageHeaderPtr-ImageAddress 0x00120000; } return XST_SUCCESS; }注意XGpioPs_ReadPin()需要先调用XGpioPs_CfgInitialize()初始化GPIO实例这部分代码通常在main()函数开头已有编译FSBL工程确保无警告。编译后的fsbl.elf文件就是MultiBoot的“大脑”。3.2 镜像生成与烧写bootgen命令详解与Vivado GUI避坑指南生成最终烧写文件是整个流程中最容易出错的环节。Xilinx提供了两种方式命令行bootgen和Vivado GUI的Program Flash。我强烈推荐先掌握命令行因为它透明、可控能暴露所有问题。命令行bootgen实操。假设你的工程目录结构如下project/ ├── sdk/ │ ├── fsbl/ │ │ └── Debug/ │ │ └── fsbl.elf │ └── app/ │ └── Debug/ │ └── app.elf ├── vivado/ │ └── project.runs/ │ └── impl_1/ │ └── system_wrapper.bit └── bifs/ └── multiboot.bif首先编写multiboot.bif文件// multiboot.bif the_ROM_image: { [bootloader] ./sdk/fsbl/Debug/fsbl.elf [address0x00021000, typebitstream] ./vivado/project.runs/impl_1/system_wrapper.bit [address0x00120000, typebitstream] ./vivado/project.runs/impl_1/system_wrapper_backup.bit [offset0x00020000] ./bifs/bootimage_table.bin }然后执行bootgen命令bootgen -image multiboot.bif -arch zynq -w -o i multiboot.bin参数解析-image指定BIF文件路径-arch zynq目标架构必须是zynq不是zynqmp-w生成宽字节widebin文件适配QSPI dual mode如果用single mode去掉此参数-o i输出为Intel Hex格式.mcs但这里我们用-o i生成.bini代表binarymultiboot.bin输出文件名。提示bootgen会输出详细的日志包括每个镜像的地址、大小、校验和。务必检查日志中Image Length是否与你计算的一致。例如如果system_wrapper.bit转换为bin后是1048576字节1MB那么[address0x00021000]之后的下一个镜像地址必须是0x00021000 1048576 0x00120000否则bootgen会报错Address overlap detected。Vivado GUI烧写避坑。如果坚持用GUI路径是Tools - Program Device - Program Flash。这里有几个致命陷阱Flash Type选择下拉菜单里qspi_single对应single modeqspi_dual_parallel对应dual mode。必须与Vivado PS配置和bootgen的-w参数严格一致。选错会导致烧写后PL无法配置Offset Address填写这个值是镜像在FLASH中的起始地址。对于MultiBoot的主镜像应该填0x00000000因为ROM Bootloader从这里开始读。但很多人误填为0x00021000bitstream地址结果烧写的是一个没有Header的纯bitstreamROM Bootloader直接跳过Disable SWDT选项务必勾选ZYNQ的Software Watchdog TimerSWDT在烧写过程中可能触发复位导致烧写中断。勾选后烧写工具会自动禁用SWDTVerify选项首次烧写必须勾选。它会在烧写后逐字节读回FLASH数据与源文件比对。虽然耗时但能100%确认烧写正确。我见过太多案例因为没勾选Verify烧写看似成功实际数据错乱重启后黑屏。3.3 烧写后验证与MultiBoot切换串口调试与GPIO状态实战烧写完成后拔掉JTAG线给板子重新上电。验证分为两个层次基础启动验证和MultiBoot切换验证。基础启动验证。通过USB-UART如FTDI芯片连接PC用minicom或Tera Term打开串口波特率1152008N1。正常启动会看到类似输出Xilinx Zynq First Stage Boot Loader Release 2018.3 Jun 15 2018 - 10:23:45 ... Loading Boot Image from QSPI at address 0x00000000 ... Found valid Boot Image at address 0x00000000 Loading FSBL from QSPI at address 0x00000100 ... Executing FSBL ... ... Loading Bitstream from QSPI at address 0x00021000 ... Bitstream downloaded successfully.如果卡在Loading Boot Image...说明FLASH里没有有效的Header检查bootgen是否成功执行BIF文件路径是否正确如果卡在Loading Bitstream...且后面出现ERROR: Bitstream download failed说明bitstream地址或大小错误或QSPI通信失败。MultiBoot切换验证。这是最考验硬件设计的一步。你需要一个可靠的GPIO切换方式硬件拨码开关在MIO[10]引脚上接一个拨码开关一端接VCC1.8V一端接地中间引出到FPGA。这是最稳妥的方式软件控制在U-Boot或Linux下通过echo 1 /sys/class/gpio/gpio10/value来设置但这需要FSBL能成功加载到U-Boot属于二级验证。切换步骤将拨码开关拨到“0”接地上电。串口应显示加载BS0的log观察PL逻辑功能是否符合预期如LED流水灯速度、UART回显内容断电将拨码开关拨到“1”接VCC再上电。串口应显示加载BS1的log观察PL逻辑功能是否切换为备份版本。注意FSBL的GPIO读取是在非常早期的启动阶段此时PS端的GPIO控制器尚未被U-Boot初始化所以必须用MIO引脚而非EMIO且引脚必须配置为输入模式。在Vivado PS配置中MIO Configuration里找到MIO[10]将其I/O Type设为InputPull-up/Pull-down设为No Pull由外部电路决定电平。4. 故障排查实战从“flash download failed”到“configuration logic stuck”的全链路诊断4.1 “error: flash download failed - target dll has been cancelled”深度溯源这个报错是Vivado Programmer最常甩给用户的“万能锅”但它背后的原因千差万别。我把它归为三类按发生概率排序第一类QSPI硬件连接与时序问题占比60%。这不是软件问题而是物理层缺陷。引脚虚焊或短路用万用表测量QSPI引脚IO0~IO3, SCLK, CS对地电阻。正常应在几百欧姆以上。如果某个IO引脚电阻接近0Ω说明PCB短路或FLASH焊接不良电源噪声QSPI FLASH的VCC通常1.8V必须干净。用示波器观察VCC纹波峰值不能超过±50mV。我曾在一个项目中因LDO滤波电容失效VCC纹波达200mV导致warning: failed to communicate with the flash chip间歇性出现时序不满足ZYNQ QSPI控制器的SCLK频率上限为50MHzsingle mode或100MHzdual mode。但在实际PCB走线上高频信号易受反射影响。解决方案是在ps7_qspiIP核的Configuration中将QSPI Clock Frequency从默认的50MHz降为25MHz看是否报错消失。如果降频后正常说明PCB Layout需要优化加阻抗匹配电阻、缩短走线。第二类FLASH型号与工具链不匹配占比30%。Vivado内置的FLASH器件库有限很多国产或新型号不在其中。器件ID识别失败在Program Flash窗口点击Refresh按钮看是否能正确读出FLASH ID如Winbond的ID是0xEF4018。如果显示Unknown或0x000000说明Vivado不认识该FLASH解决方案下载Xilinx官方的flash_programmer补丁包或手动添加器件描述文件.csv。路径Vivado_Install/data/xic/flash/。新建一个winbond_w25q128jv.csv内容参考UG1083附录A包含Manufacturer ID,Device ID,Page Size,Sector Size,Block Size等字段。第三类JTAG链路不稳定占比10%。虽然报错说“dll cancelled”但根源可能是JTAG。JTAG线缆过长超过1米的JTAG线缆极易引入噪声。换成30cm以内的短线JTAG适配器供电不足某些廉价USB-JTAG适配器如Digilent HS3在驱动QSPI时电流不足。改用Xilinx官方Platform Cable USB II或给适配器外接5V电源。4.2 “when configuration logic is stuck and unable to fallback”故障树分析这个错误意味着PL配置过程超时FSBL或ROM Bootloader认为FPGA逻辑未能成功加载。原因往往隐藏在PS与PL的交互细节中。故障树根节点QSPI读取超时。FSBL从FLASH读取bitstream时会调用QspiPs_PolledTransfer()函数。该函数内部有一个超时计数器默认1000000次循环。如果在此期间QSPI控制器的RxFIFO没有收到预期字节数就会返回错误。验证方法在FSBL源码中找到QspiPs_PolledTransfer()在其末尾添加print(QSPI Read Timeout!\r\n)。如果烧写后串口出现此打印说明QSPI读取失败解决方向检查QSPI FLASH的Hold引脚是否被意外拉低Hold引脚为低时FLASH进入保持模式不响应任何命令检查CS片选信号的时序确保在SCLK有效前CS已稳定为低电平。故障树分支一bitstream损坏或地址错误。即使QSPI读取成功读出的数据也可能错误。验证方法在FSBL中读取bitstream后立即计算其CRC32并与.bit文件的CRC比对。添加代码u32 crc Xil_GetCrc((u32*)BitstreamAddr, BitstreamSize/4); print(Calculated CRC: 0x%08x\r\n, crc);正确的CRC值可在Vivado中右键.bit文件选择Properties在Bitstream Settings里查看CRC字段常见错误BIF文件中[address...]填错导致FSBL从错误地址读取读到的是一段随机数据CRC必然不匹配。故障树分支二PL逻辑内部复位问题。PL配置完成后会释放pl_resetn信号。但如果PL逻辑内部有长延时的复位电路会导致PS认为PL“卡住”。验证方法用逻辑分析仪抓取pl_resetn信号。正常情况是PS配置PL后pl_resetn从低电平跳变到高电平持续时间应大于PL逻辑的startup clock周期通常几个us解决方法在PL逻辑顶层添加一个简单的STARTUP_PRIMITIVE并确保其CFG_FRAME信号正确连接。或者在Vivado中Settings - Bitstream - General勾选-g UnusedPin:Pullup避免未用IO悬空导致PL内部逻辑异常。4.3 “cannot load flash device description”与“flash attention”类报错应对策略这类报错通常出现在Vivado较新版本2019.1中源于Xilinx对FLASH编程算法的重构。“cannot load flash device description”。这表示Vivado找不到FLASH的编程算法.elf文件。根本原因Vivado安装目录下的Vivado_Install/data/xic/flash/文件夹中缺少对应FLASH型号的.elf算法文件解决方案访问Xilinx官网支持页面搜索你的FLASH型号如W25Q128JV下载最新的flash_programmer包。解压后将其中的.elf文件复制到上述目录。重启Vivado。“flash attention”。这是一个硬件级警告FLASH芯片通过/HOLD或/WP引脚向控制器发送状态信号。触发条件当FLASH处于Write Protect状态时/WP引脚被拉低当FLASH忙于擦除/写入时/BUSY引脚通常复用/IO2为高电平诊断方法用示波器测量/WP和/BUSY引脚电平。正常待机时/WP应为高电平1.8V/BUSY应为低电平常见误区有人将/HOLD引脚悬空导致FLASH随机进入Hold模式。正确做法是通过10KΩ电阻上拉至VCC。5. 进阶技巧与生产环境部署建议5.1 生产环境烧写从“单板调试”到“批量量产”的工程化转变实验室里用Vivado烧写一块板子和工厂里量产1000块板子是两回事。后者需要可重复、可追溯、防呆的流程。自动化烧写脚本。抛弃GUI用xsctXilinx Software Command Line Tool编写批处理脚本。示例flash_batch.tcl# flash_batch.tcl connect hw_server -url localhost:3121 open_hw_target current_hw_target [get_hw_targets */xilinx_tcf/Digilent/HS3*] refresh_hw_device [get_hw_devices xcv7020_0] set_property PROGRAM.HW_BITFILE ./bit/system_wrapper.bit [get_hw_devices xcv7020_0] set_property PROGRAM.HW_CFGMEM_PART mt25ql01g-abb1e-0-000-0 [get_hw_devices xcv7020_0] create_hw_cfgmem -hw_device [get_hw_devices xcv7020_0] -mem_dev [get_cfgmem_parts mt25ql01g-abb1e-0-000-0] program_hw_cfgmem -hw_cfgmem [get_hw_cfgmems -hier *] -file ./bin/multiboot.bin将此脚本与xsct命令结合可实现无人值守烧写xsct -eval source flash_batch.t