干FPGA这行的人十有八九都遇到过这种情况在Xilinx SDK里点一下DebugMicroBlaze跑得好好的printf也出来了DDR读写也正常可是一断电再上电板子就像失忆一样程序全没了。要是只是自己调试倒也无所谓重新下载一次就行可一旦到了现场部署、批量出货的阶段总不能每块板子都叫人开着Vivado接JTAG跑一遍SDK吧这里面的关键就是很多人没搞懂BIT文件和ELF文件之间的关系。简单说BIT是FPGA的硬件配置文件决定了逻辑电路长什么样ELF是MicroBlaze的软件程序文件决定了CPU执行什么指令。MicroBlaze是一个软核处理器它的程序代码存放在FPGA内部的Block RAM或其他存储资源里上电时由FPGA配置过程一并初始化。也就是说你要让板子上电就能自动跑程序必须先把ELF合并进BIT文件里生成一个自带程序的配置文件。这篇文章就专门讲这件事怎么把MicroBlaze的BIT和ELF高效整合生成脱机可用的download.bit再进一步固化到Flash里让板子一上电就自动运行。适合被在线调试烧录折磨过、准备做量产烧录、或者想彻底搞明白FPGA软核启动机制的工程师参考。1. 为什么非要整合BIT和ELF1.1 MicroBlaze软核的启动机制MicroBlaze是Xilinx现在叫AMD提供的32位软核处理器所谓软核就是它没有固定的物理硬件而是用FPGA的逻辑资源搭出来的一个CPU。这就带来一个特点你写的那段C代码编译出来的ELF文件并没有一个独立的程序存储器可以长期保存所有指令都依靠FPGA的配置数据流在每次上电后写入内部RAM。具体到硬件结构上MicroBlaze通常通过Local Memory BusLMB连接一块或多块Block RAMBRAM。程序启动时处理器从复位向量地址开始取指执行这个复位向量一般被linker script设置在BRAM的起始地址。那么问题来了上电瞬间BRAM里是空的CPU取到的全是0程序怎么可能跑起来答案就是FPGA的初始化机制。FPGA在配置阶段会把bitstream里的数据加载到BRAM中包括MicroBlaze要执行的指令。因此只要把ELF文件里的可执行代码提前塞进BIT文件对应的BRAM初始化数据区那么在FPGA配置完成、MicroBlaze解除复位开始取指时指令已经在BRAM里等着了。这就是整合BIT和ELF最根本的逻辑。很多人会问那我在SDK里Debug的时候不是也没手动整合吗没错SDK/GDB调试时工具链会自动做这件事先把BIT下载到FPGA再把ELF通过JTAG写入BRAM然后设置PC指针开始运行。但这个过程依赖PC主机和JTAG掉电就没了。真正要做的固化或脱机运行就必须把ELF预先合入BIT或者通过Bootloader方案从外部Flash加载。1.2 不整合会遇到哪些实际问题不整合BIT和ELF最直接的后果是板子无法脱离开发环境独立运行。具体表现有三类第一类上电后FPGA配置成功但MicroBlaze不工作。逻辑分析仪看总线一片死寂复位释放后没有取指动作因为BRAM里是空的或者全是无效数据。这种情况在你自己实验室里还能接受但现场装机的板子就彻底罢工了。第二类程序跑飞或行为异常。有些工程在SDK里调试正常把BIT单独下载后上电程序却跑出乱码、卡在异常向量。表面看像是代码有bug实际是BRAM里根本没有完整的程序镜像或者程序的data段、堆栈区没有正确初始化。第三类产线烧录无从下手。工厂烧录工人不会打开Xilinx SDK去点Debug他们要的是一个文件——一个可以直接烧进FPGA或者Flash、烧完就交付的成品镜像。没有整合好的BIT/固件文件整个产线流程就卡住了。从工程效率角度看手动在SDK里做下载BIT下载ELF的流程每块板子要折腾好几分钟还容易因为程序版本和硬件版本不匹配导致烧错。整合出一个统一的download.bit然后用脚本批量烧录效率能高出几个数量级。这也是我强烈建议所有MicroBlaze项目都把存储生成这一步纳入常规构建流程的原因。1.3 整合的本质用MMI文件做地址翻译听上去很高端其实整合的原理并不复杂。Vivado在综合、实现MicroBlaze硬件系统时会知道每个BRAM在系统地址空间中的位置以及这些BRAM在bitstream里的初始化数据区域对应关系。这些信息被记录在一个叫做MMIMemory Map Information内存映射信息的文件里。updatemem所做的工作就是读取MMI文件找到ELF里每一个要被加载到BRAM的数据目标地址把指令和初始化数据换算成bitstream里对应BRAM初始化块的物理位置然后写入BIT文件。这个过程相当于给软件工程师提供了一个无需关心FPGA底层只要指定ELF地址和数据映射就能自动完成加载的桥梁。所以整合不仅是把两个文件拼在一起而是通过MMI文件做了一次精细的地址翻译。这也是为什么每次修改了硬件工程BRAM大小、地址映射变了之后必须重新生成MMI和BIT再重新整合ELF的原因。如果用了旧的MMI去整合新的ELF地址错位几乎是必然的。2. 整合前的准备工作2.1 三样关键文件BIT、MMI、ELF在动手整合之前先把需要的文件备齐。一共三样BIT文件来自Vivado硬件工程的综合实现结果一般在工程目录下的工程名.runs/impl_1/里例如system_wrapper.bit。这是整个FPGA逻辑的配置文件。MMI文件同样在实现目录中通常是工程名.runs/impl_1/system_wrapper.mmi。这个文件描述了硬件系统中BRAM的地址映射关系。需要注意的是不是所有工程都会自动生成MMI如果impl目录下找不到可以用Tcl命令手动生成具体方法见下文。ELF文件来自Xilinx SDK或Vitis编译生成的微处理器应用程序一般在SDK工程的Debug/或Release/目录下例如hello_world.elf。注意要选用最终交付的那个版本调试版本和发布版本生成的ELF内容可能不同尤其是优化选项和调试信息会影响代码段布局。经常有同事问我没有MMI文件怎么办其实Vivado里有个Tcl命令可以在任何时候重新生成它。打开Vivado的Tcl Console切换到实现后的结果执行open_run impl_1 write_mem_info D:/project/project_1/project_1.runs/impl_1/system_wrapper.mmi这个命令会按当前实现的BRAM分配情况重新生成MMI文件。如果你是严格按照综合→实现→生成比特流流程走完的通常在impl_1目录下就能找到默认生成的MMI文件名和工程wrapper名字一致。但如果Vivado版本或工程设置比较特殊没有生成用上面这条命令手动补一个就行。2.2 ELF链接地址必须和硬件匹配很多人整合完下载发现程序还是跑飞原因不在整合本身而是linker script里的地址和MMI里的地址对不上。MicroBlaze的linker script在SDK中是可以配置的里面定义了代码段、数据段、堆栈段落在内存中的位置。最常见的情况是硬件里BRAM只分配了64KB但linker script把堆栈或堆设置得很大或者把代码段加载地址设到了DDR里0x80000000。这种ELF如果硬整合进BIT要么updatemem直接报错说地址越界要么程序放到BRAM里根本跑不动——因为MicroBlaze执行第一条指令就需要从DDR取指而DDR此时还是空的。所以在整合前务必确认三件事linker script的起始地址通常是复位向量等于硬件中BRAM的基地址常见的是0x00000000或0x00000050等以BD里MicroBlaze配置为准整个程序的代码段数据段堆栈空间总和不超过BRAM实际容量如果程序跑在DDR里就必须有配套的Bootloader方案不能简单把ELF塞进BIT。一个判断小技巧在SDK里打开lscript.ld文件看_stack和_heap的地址范围再对比Vivado Block Design里MicroBlaze的LMB BRAM地址范围就能很快发现问题。这个问题排查看似简单但现场出问题时十有八九是它。2.3 操作环境准备整合命令在Vivado Tcl Console里就能执行不需要单独开SDK。但如果你想把整合过程自动化建议写在Tcl脚本里用Vivado的batch模式统一跑。常用的办法是在命令行执行vivado -mode batch -source merge.tcl这样每次生成完新的BIT和ELF跑到这个脚本就自动合并产线上也方便。Vivado 2018.3到2020.1这个区间updatemem命令的用法基本一致从2020.2开始进入Vitis时代命令参数略有调整但核心逻辑没有变。如果你用的是Vitis在Xilinx Software Command Line Toolxsct或Vivado Tcl里依然可以调用updatemem。我下面给的命令示例用的是最通用的老版本格式新版也兼容。3. updatemem实操把ELF装进BIT3.1 命令格式和参数逐项拆解updatemem命令的完整参数很多但日常项目里真正用到的就那么几个。最典型的调用方式如下updatemem -force -meminfo D:/project/project_1/project_1.runs/impl_1/system_wrapper.mmi \ -data D:/project/sdk_workspace/app/Debug/app.elf \ -bit D:/project/project_1/project_1.runs/impl_1/system_wrapper.bit \ -proc system_i/microblaze_0 \ -out D:/project/download.bit逐个参数解释一下-force允许覆盖同名输出文件。如果你之前已经生成过一次download.bit不加这个参数会报错提示文件已存在。-meminfo指定MMI文件路径。注意路径尽量用绝对路径避免相对路径在不同工作目录下踩坑。-data指定要写入的ELF文件路径。这里可以是ELF格式也可以是bin格式但ELF最常用因为updatemem能直接从ELF里解析出加载地址和段信息。-bit输入BIT文件路径也就是硬件工程生成的原始比特流。-proc指定MicroBlaze处理器的实例名。这是一个很容易被忽略的参数。如果你的Block Design里只有一个MicroBlaze加不加可能都能通过但如果BD里有多核或者处理器实例名比较特殊不加这个参数命令会直接报错“multiple processors found”。-out输出整合后的BIT文件路径。还有一个参数在某些场景很实用-debug。它会在BRAM里的内容不是有效指令时自动填充一段跳转到自身死循环的代码。调试硬件逻辑时这个参数能帮忙避免程序跑飞到完全随机的数据上。3.2 实测案例单MicroBlaze工程整合全过程为了避免纸上谈兵我拿一个实际工程走一遍完整流程。假设工程结构如下硬件工程D:/project/project_1/project_1.xprBlock Design名称system顶层wrappersystem_wrapperMicroBlaze实例microblaze_0SDK工程名app生成结果目录project_1.runs/impl_1/第一步先在Vivado里重新生成BIT并确认MMI文件存在。打开Vivado Tcl Console执行open_project D:/project/project_1/project_1.xpr open_run impl_1 write_mem_info D:/project/project_1/project_1.runs/impl_1/system_wrapper.mmi如果之前已经正常Generate Bitstreamimpl_1目录下一般已经有MMI文件这步可以跳过。但多执行一次不亏能确保MMI和当前实现结果一致。第二步在SDK里编译应用确保生成最新的ELF。编译完成后确认app/Debug/app.elf文件时间戳是刚刚生成的。第三步在Vivado Tcl Console里执行整合命令updatemem -force -meminfo D:/project/project_1/project_1.runs/impl_1/system_wrapper.mmi \ -data D:/project/sdk_workspace/app/Debug/app.elf \ -bit D:/project/project_1/project_1.runs/impl_1/system_wrapper.bit \ -proc system_i/microblaze_0 \ -out D:/project/download.bit执行完如果终端输出了类似Updating block RAM initialization data...的信息没有报错就说明整合成功。此时在D:/project/下会多出一个download.bit文件大小和原始BIT差不多但内部BRAM初始化数据已经被ELF内容填满了。第四步验证整合结果。打开Vivado Hardware Manager连接开发板把download.bit下载到FPGA里。如果一切正常上电后MicroBlaze会自动开始执行程序串口能看到输出。如果程序里写了LED翻转也能看到LED按预期闪烁。这一步是检验整合是否成功的最终手段不要省。3.3 多个MicroBlaze或多个ELF时的处理有些复杂系统会在一颗FPGA里放两个甚至多个MicroBlaze。这时整合逻辑一样只不过要对每个处理器分别调用一次updatemem分别指定各自的-proc参数和ELF文件。比如有两个MicroBlaze分别是microblaze_0和microblaze_1就执行两次updatemem -force -meminfo D:/project/project_1/project_1.runs/impl_1/system_wrapper.mmi \ -data D:/project/sdk_workspace/app0/Debug/app0.elf \ -bit D:/project/project_1/project_1.runs/impl_1/system_wrapper.bit \ -proc system_i/microblaze_0 \ -out D:/project/download.bit updatemem -force -meminfo D:/project/project_1/project_1.runs/impl_1/system_wrapper.mmi \ -data D:/project/sdk_workspace/app1/Debug/app1.elf \ -bit D:/project/download.bit \ -proc system_i/microblaze_1 \ -out D:/project/download_final.bit注意第二次调用的-bit参数要填第一次的输出结果-out换一个新文件名这样两个ELF才能依次合并进同一个BIT。如果你直接两次都用原始BIT作为输入后一次会把前一次覆盖掉结果只有一个处理器的程序被合进去了。还有一个细节多ELF整合时必须确保两个处理器的程序在BRAM空间上没有重叠。MicroBlaze的BRAM通常是各自独立的LMB接口所以两个处理器各用自己的BRAM地址空间天然隔离一般不会冲突。但如果你把两个核的BRAM挂到了同一个BRAM控制器上就要特别注意linker script的分配否则updatemem可能会检测到地址重叠并报错。4. 从download.bit到真正固化4.1 在线下载和Flash固化的本质区别好了现在你手里有一个整合了程序代码的download.bit把它下载到FPGA里MicroBlaze就能脱离PC跑起来。但这里有个坑只要掉电FPGA配置数据还是会丢。download.bit只存在于RAM里断电即失忆。所以量产场景下还需要最后一步把配置数据固化到非易失性存储介质里通常是QSPI Flash、SPI Flash或者SD卡。FPGA上电后通过配置模式主动从这些介质读取bitstream然后自动完成加载。市面上常见开发板的配置模式有Master SPI、Slave SelectMAP、JTAG等。MicroBlaze项目最常用的是QSPI Flash所以下面我说的下载方案都围绕它展开。固化和在线下载的核心区别在于在线下载是临时烧进RAM固化是永久写进Flash。固化后的板子在电子工程意义上已经是一个完整的嵌入式系统了上电即运行和普通单片机控制板没有本质区别。4.2 用Vivado生成MCS/BIN固件文件接下来要把整合好的download.bit转换成Flash可以接受的文件格式。Vivado的write_cfgmem命令就是干这个的。最常用的格式是MCSIntel HEX的变体和BIN。MCS文件带地址信息和校验适合用烧录器或Vivado Hardware Manager烧写BIN文件是纯粹的二进制映像适合产线用通用烧录器或者读回验证。打开Vivado Tcl Console执行以下命令生成MCSwrite_cfgmem -format mcs -interface SPIx4 -size 16 \ -loadbit data 0x0 D:/project/download.bit \ -file D:/project/system.mcs参数说明-format输出格式mcs或bin。-interfaceFlash接口类型。多数开发板QSPI Flash用的SPIx4如果你的板子FLASH接法特殊要按原理图调整。-sizeFlash容量单位是Mb还是MB这里用的是Mb。比如16MB的Flash写168MB写8。如果写错生成的MCS地址范围可能不对。-loadbit指定要转换的BIT文件及加载地址。data 0x0表示从偏移0地址开始存放这是最常见的配置。-file输出文件名。如果只需要BIN格式就把-format bin。BIN格式适合直接烧写到Flash偏移0地址产线批量烧录时比MCS更方便。4.3 Flash烧录的两种实用方式生成MCS/BIN之后烧录Flash有两条路图形界面和命令行。图形界面方式最简单打开Vivado Hardware Manager连接开发板右键点击FPGA器件选择Add Configuration Memory Device选择你板子上对应的Flash型号然后加载MCS文件点Program。等待进度条跑完断电重启验证程序是否自动运行。命令行方式更适合批量生产。在Vivado Tcl Console或者SDK命令行下调用program_flash工具program_flash -f D:/project/system.mcs -offset 0x0 \ -flash_type s25fl128sxxxxxx0-spi-x1_x2_x4 \ -fsbl D:/project/fsbl/Debug/fsbl.elf \ -cable type xilinx_tcf url TCP:127.0.0.1:3121这里需要给每个开发板指定Flash类型参数不同板子的Flash型号不同-flash_type参数要按实际芯片来。-fsbl需要指定FSBLFirst Stage Boot Loader的ELF如果工程里没有生成FSBL也可以用Vivado Hardware Manager图形界面方式来规避这个问题。烧录完一定别忘了验证断开JTAG、断电、重新上电观察程序是否自动运行。这一步如果跳过有可能出现烧的时候显示成功实际板子没跑的虚假安全感。5. 常见坑与排查思路5.1 updatemem报错速查表下面这张表是我在实际项目中见过最多的报错直接整理出来方便对照报错信息原因解决办法Could not find memory map informationMMI文件路径错误或MMI文件不存在检查路径用write_mem_info重新生成Multiple processors foundBD里有多个MicroBlaze未指定实例名加上-proc参数指定具体的处理器实例Address out of rangeELF的加载地址超出了BRAM地址范围检查linker script和BD中BRAM大小调整代码或扩容Data file not found / access deniedELF文件路径错误或权限问题使用绝对路径并确认文件可读Output file already exists输出文件已存在且未加-force加-force参数覆盖或换个输出文件名ERROR: Cannot read ELFELF格式异常或文件损坏重新编译生成ELF确认是有效的可执行文件这些报错本身不可怕可怕的是报错信息里没有明确指向根因需要逐项排除。我的经验是先查MMI路径再查proc名字最后查代码大小这三个是最常见的坑。5.2 ELF放不下BRAM了怎么办这是MicroBlaze工程后期非常常见的问题程序功能越来越多BRAM内存不够用了。一种解决思路是扩大BRAM。在Vivado Block Design里双击MicroBlaze把LMB BRAM的容量调大重新生成bitstream和MMI。但FPGA内部BRAM资源有限而且BRAM增大意味着逻辑资源占用变多还可能导致时序收敛变难。第二种思路是把程序放到外部DDR里运行。此时不能只依赖updatemem把完整ELF塞进BIT因为DDR上电时是空的需要一个Bootloader先从Flash把这里的应用程序加载到DDR再由Bootloader跳转过去执行。这种方案需要额外编写FSBL或Bootloader并配置SDK生成不同的boot镜像复杂度提升不少。第三种思路是精简代码。检查linker script里堆栈、堆的大小设置把不需要的库去掉把printf这类重函数换成轻量实现。有时候仅靠这些调整就能把程序从放不下变成刚好放下。在实际项目中我倾向于一开始就把BRAM设置为需求值的两倍左右并在linker script里预留足够余量避免开发后期反复改硬件结构。改动硬件结构不是不行但它会导致原来的整合配置全部推倒重来成本很高。5.3 上电不跑、跑飞、时序不稳定的排查整合完也烧录了但板子还是不正常这个问题最让人头疼。先例行检查上电后FPGA是否配置成功。用示波器或LED确认PROG_B、DONE信号状态DONE拉高说明FPGA配置完成。如果DONE一直不拉高排查配置源和Flash焊接。再确认MicroBlaze的复位是否正常释放。有的工程把MicroBlaze的复位信号接在了一个需要外部触发的信号上上电后一直不复位程序自然不跑。查看Block Design里reset模块的连接确保上电自动释放复位。还有一种情况是程序整合进去了也能跑但跑几秒就死机。优先怀疑Watchdog、中断、时钟频率配置不匹配。MicroBlaze外设的时钟频率在Block Design里配置而外设驱动里的时钟参数通常由BSP生成正常情况下一致但如果你手动改过FCLK频率或者外设IP的时钟分频驱动可能跑错时序。最后说一个很容易被忽略的点在Vivado里每次修改了硬件工程哪怕是只改了一个引脚约束都要重新生成BIT和MMI然后重新执行updatemem。如果SDK里的app代码没变但硬件变了只更新BIT却不更新ELF的整合参数极大概率会导致程序运行异常。我见过太多项目死在这个问题上——明明所有步骤都对就是忘了在修改硬件后重跑一遍整合。我个人在实际操作中会把整合命令写成一个Tcl脚本和工程放在同一个目录下。每次Build完硬件和软件直接跑一遍脚本就能得到新的download.bit再从硬件管理器里烧写固件整个流程几分钟搞定出错的概率也低很多。最后再分享一个小技巧整合完的download.bit不要覆盖原始BIT文件单独命名存放这样哪天要回退到纯硬件配置调试逻辑时原始BIT还在手上不至于被污染。
