FPGA烧写和固化还分不清？从bit文件到Flash上电启动一次讲透

做FPGA这些年，被问得最多的问题不是“怎么把逻辑写出来”，而是“bit文件都生成了，下载到板子上能跑，断电再上电就白屏，怎么办”。答案往往就是一句话：你只做了烧写，没做固化。

Vivado里这两个词经常被混着用，但实际是两条完全不同的路径。烧写（Program/Configure）是把bitstream临时加载到FPGA内部的SRAM配置区，掉电就丢，主要用来调试；固化则是把程序写进外部Flash（QSPI Flash、BPI Flash、SD卡等），上电后由FPGA自己从Flash加载，这才是真正能交付、能批量生产的形态。很多人卡在“为什么我下载没问题，一上电就白屏”“为什么烧写Flash报错”“为什么校验失败”，本质都是没把这条链路理顺。

这篇文章我是按“从原理到操作、从纯FPGA到Zynq再到MicroBlaze、从成功到翻车”的顺序写的。包括flash镜像格式怎么选、Vivado图形界面和Tcl命令怎么配合、Zynq的BOOT.BIN怎么生成、软核场景下bit和elf怎么合并、以及我整理过很久的报错速查表。适合所有用Vivado开发、正在被“烧写/固化”折磨的工程师和学生。

1. 先别急着点Program，搞清楚你要写到哪里去

1.1 临时加载是调试用的，断电就没

FPGA的配置原理其实不复杂。芯片内部有一块SRAM，用来存放LUT、FF、BRAM的配置内容，上电后这块SRAM是空的，必须把bitstream灌进去，逻辑才能跑起来。Vivado的Hardware Manager里点Program Device，走的是JTAG口，把数据一条一条写进这块SRAM。这个过程很快，几秒钟就能看到结果，适合每改一次代码就验证一下。

但这个模式有两个天然缺陷：一是断电后SRAM内容清零，重新上电又变回“白屏”；二是JTAG口只在调试阶段连着，交付给现场的设备不可能拖着一根下载线跑。所以但凡你的板子要脱离电脑独立运行，就必须走固化的路子。我见过不少新手开发板调了半个月，天天上电都要先插下载线load一下，还以为是正常流程，其实是绕过了固化这个环节。

1.2 固化才是“能出货”的形态

固化的本质是把配置文件写到板载的非易失存储器里，常见有QSPI NOR Flash、BPI Flash、SD卡、eMMC。上电后FPGA会按照模式引脚（M[2:0]）的配置，主动从Flash里读出配置数据并加载自己，完全不需要电脑参与。注意这个“主动加载”是FPGA硬件自带的启动流程，不是软件启动，所以哪怕你的逻辑里有个时钟都没起来，加载过程照样会执行，只要Flash里的镜像格式对、启动模式拨对了，它就能跑起来。

用表格直观对比一下：

所以你的第一步不是打开Vivado乱点，而是先问自己：我现在是只调逻辑，还是要把程序“装”到板子上让它独立跑？前者只需要bit流，后者必须做固化。后面所有内容都以这个区分为前提。

2. 固化前必须搞懂的三个文件格式：bit、bin、mcs

2.1 bit不是拿来直接写Flash的

很多新人第一次固化时，直接在Hardware Manager里把.bit文件当成Flash的写入文件用，然后发现要么选不了、要么写完上电白屏。原因在于.bit文件是Vivado给JTAG/调试用的原始配置流，它头部带了一堆额外信息，包括同步字、时间戳、设备ID码、寄存器初始化段，这些是为“下载到SRAM”设计的。Flash启动时FPGA要的是从首地址开始连续、紧凑、符合自己启动协议的配置数据，所以必须先做格式转换。

一句话总结：bit是“工程中间产物”，bin/mcs才是“Flash能识别的东西”。这个认知能帮你省掉后面一大半的报错。

2.2 bin和mcs到底有什么区别

bin是纯二进制镜像，从Flash起始地址开始，一个字节接一个字节的原始数据，没有任何帧结构。mcs是Intel Hex格式的变体（也被称为HEX记录），它把数据按地址分段，每段都带地址信息和校验值。换句话说，bin是“没地址的裸数据”，mcs是“带地址地图的数据包”。

从使用场景看：

• 用Vivado图形界面固化，mcs最省心。你在Add Configuration Memory Device里选择型号时，Vivado会自动把bit转成mcs并写入，不用手工处理地址。
• 用write_cfgmem命令生成镜像，bin更通用。bin文件可以被第三方烧录器、U-Boot、SD卡启动等直接使用，尤其是Zynq场景下，U-Boot里加载的BOOT.BIN本质就是bin的变体。
• 板卡用的Flash若大于16MB（128Mb），一般需要带4字节地址模式的bin或mcs，普通地址模式会寻址溢出，这个后面细说。

2.3 版本差异和命名误区

Vivado不同版本对配置文件格式的处理差不多，但菜单位置变过。2019.2以后SDK逐渐被Vitis替代，Hardware Manager的界面也调整过；2023.1以后Hardware Manager汉化不到位，很多按钮还是英文。这些都不要紧，重要的是你脑子里的链路不能乱：bit转bin/mcs，再写Flash，再校验，再上电验证。无论工具怎么改，这条链永远是死的。

3. 纯FPGA固化全流程实操：从图形界面到命令行

3.1 硬件准备与连接检查

先确认几件事：下载器是Xilinx Platform Cable USB II还是Digilent HS3/HS2，驱动是否装好；JTAG链上有没有多个器件；板卡烧写时要供上电，尤其是配置Bank的电压（通常1.8V或3.3V，具体看原理图）；Flash型号要查清楚，最好看板卡原理图，确认具体型号和封装，别靠猜。

连接好之后打开Vivado，点击Open Hardware Manager，Open Target，正常情况下能看到JTAG链上的设备。如果这里就识别不出来，后面全白搭。识别不到的原因八成是驱动、线序或者供电，先解决这个再继续。

3.2 方法一：图形界面烧写mcs，最稳但最慢

这是我最推荐新手走的第一步，因为每一步都有图形提示，报错也直观。

操作路径是：Hardware Manager里右键设备 -> Add Configuration Memory Device，弹窗里搜索你的Flash型号。以常见的Spansion/Cypress S25FL128、Winbond W25Q128为例，选好型号后，在Configuration File那一栏填入你的.bit文件。Vivado会自动生成一个.mcs和一个.prm文件，然后弹出一个烧写窗口，里面默认勾选了Erase、Blank Check、Program、Verify四步。

我的建议是默认全勾，不要偷懒只选Program和Verify。Blank Check能提前发现Flash里有没有残留的坏块或者锁定位；Verify在写完后再读一遍对比数据，防止写的瞬间出错。整个流程下来，128Mb Flash大概需要几分钟，耐心等。

烧写完成后，把板子断电、重新上电，观察你的功能是否正常。如果白屏，先别急着怀疑Flash，回头检查启动模式拨码开关（SPI/QSPI挡位）。很多板卡上电不启动，不是没写成，是FPGA根本没处于“从SPI加载”的模式。

3.3 方法二：Tcl命令行生成bin，批量交付神器

图形界面适合单板调试，但你要是做了十块板子，还要一块块开GUI去点，效率太低。这时候建议直接在Vivado Tcl Console里用write_cfgmem，一次性生成bin镜像，后续检查对着bin的CRC/大小就行。

以Artix-7、QSPI x4、Flash容量128Mb为例，命令是：

write_cfgmem -force -format bin -interface spi4x1 -size 128 -loadbit "data 0x0 top.bit" top_boot.bin

逐个参数说：

• -format bin：生成二进制镜像；要生成mcs就把这里改成mcs。
• -interface spi4x1：Flash挂在哪个接口。Artix-7常见的QSPI Flash如果是x1启动，用spi1x1；支持x4模式就用spi4x4或spi1x4，具体看你的原理图和IP配置。选错接口会导致上电加载时序不匹配，白屏。
• -size 128：这个参数的单位是Mb，不是MB。128就是128Mb，对应16MB。如果你用256Mb Flash就是256，别把MB换算进去，这是很多人踩的坑。
• -loadbit "data 0x0 top.bit"：表示从Flash地址0x0开始加载bit文件。如果你的板卡还需要在0x0之前放一段配置头，这里可以相应调整地址偏移。

生成之后，你可以用第三方烧录器（如ChipProg、研华等）直接把这个bin写进Flash，批量产线基本都这么干。或者如果你只有一根JTAG下载线，把这个bin给同事，让他用Vivado图形界面烧写时选择这个bin文件，效果一样。

3.4 时钟和DRC报错：RTSTAT-2到底在说什么

很多人在implement阶段就会遇到一个和固化强相关的DRC报错，代码是[DRC RTSTAT-2]。这个报错出现时，综合和布局布线结果还在，但它会挡住bit生成，导致你根本没有可烧的文件，更谈不上固化。

RTSTAT-2核心问题是Configuration Bank的状态不满足要求。最常见的原因是配置时钟（CCLK）频率设置得非标、配置Bank电压和CFGBVS引脚的电平不匹配、或者模式引脚对应的I/O标准不对。解决办法是回头检查工程约束里的配置属性：

set_property BITSTREAM.CONFIG.CONFIGRATE 30 [current_design] set_property BITSTREAM.CONFIG.CONFIGVOLTAGE 1.8 [current_design]

第一句把CCLK设成30MHz，第二句把配置电压设为1.8V。这两个数值要和你板卡的Flash实际工作电压、你给FPGA配置Bank的供电对得上。如果你的Flash是3.3V供电而这里写成1.8V，烧写的时候可能能写进去，但上电加载会出错。遇到RTSTAT-2，我的排查顺序是：先看CFGBVS引脚接法，再看配置Bank电压，最后看CONFIGRATE是否在5~50MHz之间的标准值。

3.5 几个纯FPGA固化的经验技巧

第一次烧写前先做一个“最小验证”：把板卡拨码开关拨到QSPI模式，找一个验证过的bit，固化一遍，断电上电，能跑起来再开始搞你真正的逻辑。这样能区分“固化流程有问题”和“你的工程有问题”。

Flash型号一定要选对，一个常见翻车现场是板卡用的是S25FL256S，但Vivado里搜出来S25FL256L，型号后一个字母不同，指令集和扇区结构就可能有差异，写进去校验通过，上电却白屏。选型号时对着原理图、对着Flash丝印、对着Vivado支持的列表一个个核对，别嫌麻烦。

如果你的Flash容量超过16MB，Vivado生成镜像时要选带“4 Byte Address”的interface，比如spi4x4、spi2x4，否则地址高字节写不进去，加载时只能访问到低16MB，程序跑飞。

4. Zynq和MicroBlaze场景下的固化，不是同一个玩法

4.1 Zynq平台：BOOT.BIN才是灵魂

Zynq的固化跟纯FPGA有一个本质区别：Zynq的启动顺序是先由BootROM代码读取启动设备里的BOOT.BIN，BOOT.BIN里包含FSBL（First Stage Boot Loader）、PL的bitstream、以及用户应用（PS侧的elf）。所以你不能像纯FPGA那样只写一个bit进Flash，你得把整个BOOT.BIN烧进去。

生成BOOT.BIN的路径是：先写好FSBL（SDK会自动生成一个模板工程），然后准备一个bif描述文件，用bootgen工具打包。bif内容大致如下：

the_ROM_image: { [bootloader]fsbl.elf [destination_device=pl]system.bit [destination_cpu=ps7_cortexa9_0]app.elf }

然后执行命令：

bootgen -image boot.bif -o i BOOT.BIN -w on

-w on表示强制覆盖同名文件。如果你的工程是Zynq UltraScale+，destination_cpu要改成ps0_cortexa53_0；如果PL侧不需要逻辑，可以不写system.bit那一行。注意BOOT.BIN里的顺序是有讲究的，FSBL必须写最前面，否则BootROM识别不了。

4.2 把BOOT.BIN写进QSPI的三种路径

Zynq烧写BOOT.BIN的方式比纯FPGA多种，我按推荐程度排序。

第一种，用Vivado Hardware Manager直接烧QSPI Flash。在Hardware Manager里选中Zynq的PL设备（或者PS设备节点），Add Configuration Memory Device选你板上的QSPI型号，然后选择BOOT.BIN作为烧写文件。这种方式最简单，但速度慢，适合小批量。

第二种，用XSCT工具走JTAG间接烧写。在Vivado的XMD/XSCT下先把FSBL加载进DDR，再通过FSBL的驱动把PC端的镜像写到QSPI。SDK里有一个Program Flash向导，选好FSBL、选好BOOT.BIN，它会自己走这个流程。这种方式比直接写Flash可靠，因为Flash接口时序由FSBL初始化好了，不会出现PN电压不匹配的问题。

第三种，用U-Boot烧写，适合批量产线和现场升级。板子先在SD卡/QSPI里跑起来U-Boot，然后通过tftp从服务器拉BOOT.BIN，在U-Boot命令行执行：

setenv ipaddr 192.168.1.10 setenv serverip 192.168.1.100 tftp 0x03000000 boot.bin sf probe 0 0 0 sf erase 0x0 0x400000 sf write 0x03000000 0x0 0x400000

注意sf erase的地址和大小要和sf write一致，文件多长就擦多长，不要贪多，也不要少擦。擦除长度算错是最常见的“烧完还是旧程序”的根源，因为新程序写了，但没覆盖干净，老代码残留在后半段。

4.3 串口烧写失败到底该查什么

热词里有个“串口烧写失败”，我猜你遇到的情况多半是：通过U-Boot的串口命令行执行烧写，或者通过SDK的Program Flash串口模式传输镜像，结果传一半卡死、或者校验失败。先说结论：串口只适合看打印，不适合传大文件，能走网络就走网络。

如果是U-Boot下用loadb/loady从串口接收然后写Flash，先看波特率是否匹配，115200是默认，但有人改过环境变量就没同步过来。再看PC端串口工具是否占用了COM口，多个工具同时打开会导致数据字节被截断。最后是流控，DTR/RTS开不开会影响部分USB转串口芯片的行为，导致写入的镜像和原文件比对不一致。

如果是SDK的Program Flash通过JTAG+串口组合操作，失败多发生在加载FSBL之后串口跳线没切换，PC端没有正确选择对应端口。总之，烧写镜像的文件完整性是第一位的，建议烧完后用sf read把Flash内容读回来，做个md5sum和PC端文件比对，一致性是王道。

4.4 MicroBlaze软核场景：updatemem把elf合并进bit

MicroBlaze这种软核，真正跑起来的程序除了FPGA逻辑，还有一段软核要执行的C代码。裸机时代码在BRAM/DDR里，如果把bit单独固化，上电后MicroBlaze里是空的；把elf单独固化，FPGA逻辑没有，代码无处运行。所以要先合并。

Vivado工程里会生成一个MMI文件（memory map file），记录BRAM在系统地址空间的映射。用updatemem命令把elf嵌进bit：

updatemem -meminfo system.mmi -data app.elf -bit system.bit -proc system_i/microblaze_0 -out download.bit

从Vivado 2018.3及之后版本一直可以用。合并完后，把download.bit按前面第3章的流程转成bin/mcs烧进Flash。上电后MicroBlaze会自动从BRAM起始地址取指执行。有人会问为什么不用bootgen直接打包elf和bit，因为纯FPGA的启动机制不解析elf，软核程序的入口地址必须通过MMI映射写死在配置流里。

4.5 PL-only和PS-only烧写的区别

很多人分不清“PL程序烧写”和“PS烧写”。PL（可编程逻辑）烧写，就是普通FPGA固化的流程，把bit转bin/mcs写Flash，全程不涉及Linux/U-Boot；PS（处理系统）烧写，在Zynq上通常指把FSBL、U-Boot、内核、rootfs等写到SD卡/eMMC/QSPI里。如果你只有PL逻辑，不需要在Flash里塞内核，那就不要用BOOT.BIN，直接用纯FPGA的流程即可。如果你要Linux跑起来，BOOT.BIN只是启动链的第一环，后面的image.ub、rootfs也要正确落盘，任何一个环节缺了都起不来系统。

5. 烧写报错排查速查表与我的避坑经验

5.1 “检测不到设备”和“IDCODE不匹配”的排查

这是最靠前的一道关。JTAG链上识别不出设备，检查顺序是：下载器供电是否正常（Platform Cable USB II经常因为USB口供电不足导致灯都不亮）；JTAG连接线是否插反，TCK/TMS/TDI/TDO一一对应；板卡是否有独立供电；Windows下设备管理器里有没有识别到下载器设备，Digilent的要装ADE（Adaptive Digital Entertainment? 不对，是Adept Runtime），Xilinx的要看驱动装好没有；Linux下用lsusb看有没有对应USB设备。

IDCODE不匹配，通常是JTAG链上接触不良，或者你选的器件型号和板卡实际芯片型号不一致。排查方法就是看Hardware Manager里扫描到的IDCODE和芯片datasheet上的JTAG ID是否一致。不一致的话大概率是线没接好，或者板卡上有其他器件干扰，也可能是下载线质量太差，换根好的线立马解决问题。

5.2 Flash校验失败和型号选错的典型症状

烧写过程中Program通过，Verify失败，是最迷惑人的情况。我遇到过的原因按概率排序：

• Flash型号选错，导致扇区大小、写命令时序不匹配。Vivado写入时用的是它认为的扇区结构，实际芯片扇区不一致，写进去的数据自然对不上。
• Flash的WP（写保护）引脚没有被拉高。很多板卡把WP默认接地，导致芯片处于保护状态，读出来全是FF，校验必挂。看原理图确认WP和HOLD引脚有没有被正确上拉。
• CCLK/写入时钟太高。图形界面烧写时默认不让你改，但通常15MHz以下更安全。如果Flash是老型号，写太快会丢位。
• 板卡电源纹波大，写入瞬间电压跌落导致数据位错乱。这个在产线上最常见，换个稳定的适配器就好了。

5.3 上电不加载，DONE不拉高的几种原因

固化完成后上电白屏，这是“烧写成功但启动失败”。先从硬件上量DONE引脚，如果上电后DONE一直是低，说明FPGA根本没能完成配置加载。常见原因：

• 启动模式拨码开关拨错位置，FPGA没有选择QSPI启动模式，而是等了JTAG或者选了别的无效模式。7系列常见Master SPI模式对应的M[2:0]组合取决于板卡设计，一定要对着原理图核对，不要凭记忆。
• Flash布局和生成镜像时的interface不匹配。你生成bin时用的spi4x4，但板子的Flash只接了x1，或者反过来。重新按硬件实际连接生成正确的bin。
• bitstream里配置了加密或DCI模式，Flash加载时序和普通模式不一样，需要专门的配置头，没有配置头就会卡住。

5.4 常见问题速查表

5.5 比报错更可怕的“假成功”

还有一种情况最坑：固化时报All Operations Completed，断电上电功能也正常，但过了几天批量产的时候发现有一小部分板子不行。这种“假成功”多半是写入时序余量不够，或者Flash型号混料（同一丝印批次不同）。我的建议是，少量调试时可以用图形界面慢慢写，但一旦要量产，所有镜像必须用write_cfgmem统一生成，参数固定，同时在产线上增加Verify步骤，不要省。省一次的代价是批量返工。

另外提一个容易被忽视的点：Flash也有擦写寿命，反复烧写调试时最好轮流用几块板卡，别逮着一块使劲造。QSPI NOR的擦写次数通常是十万次级别，但频繁整片擦除还是会有损耗，特定扇区写多了会坏。调试阶段建议只在0x0开始的镜像区域操作，别动不动全片擦除。

6. 最后分享几个我自己的土办法

做到现在这个阶段，大部分问题你都应该能自己定位了。我最后再啰嗦几句实操层面的习惯，都是踩过坑换来的。

第一，工程里永远保留一条Tcl脚本，把bit生成和bin生成串起来。改完代码跑一遍，脚本自动输出top_boot.bin。这样无论你后面是用图形界面、第三方烧录器还是U-Boot升级，手里的镜像都是最新的，不会出现“烧的是昨天的旧程序”这种笑话。

第二，板子上的启动模式拨码开关一定要画在原理图阶段就想好。量产板建议做两个版本：开发板可以保留拨码，交付板直接焊死到QSPI模式，省去现场误拨开关导致设备起不来的麻烦。

第三，Zynq场景长期维护建议维护一个工程目录，把每一次烧写的BOOT.BIN、对应bif文件、改动说明存成一个带时间戳的文件夹。固化这块出问题最难排查的就是“到底哪个镜像对应哪次改动”，目录整理清楚了，五分钟就能定位。

我个人几年的经验是：绝大部分固化问题都不是FPGA难为你，而是文件格式、启动模式、硬件连接这三件事没对齐。把这三件事当常识记在心里，烧写固化这事真的就“看这一篇就够了”。