JFlash分段烧录实战手记：一个嵌入式工程师踩过坑后写给自己的备忘录
去年冬天调试一款车载T-Box时，我连续三天没回家——不是因为代码跑飞了，而是产线反馈：第172台设备刷完固件后无法启动，JLink识别正常但复位后停在0x08000000的非法指令上。用逻辑分析仪抓SWD信号发现，Bootloader首扇区被悄悄擦成了全0xFF。那一刻我才意识到，所谓“烧录完成”的绿色对勾，背后可能是一整片被误删的信任。
后来查清楚，是产线脚本里一句JLinkExe -CommanderScript erase_all.jlink惹的祸。它不区分地址、不看用途、不问后果，只管把Flash从头到尾犁一遍。而我们的密钥区、校准参数、DFU跳转表，全都躺在那片“待擦除”的土地上，像没收到撤离通知的村民。
这件事逼着我重读JFlash手册第5章、翻遍STM32H7和i.MX RT1176的参考手册、对比十几份.jflash项目文件，最终把“分段烧录”从一个模糊概念，变成了每天开工前必检查的五条铁律。今天这篇笔记，不讲高大上的架构图，也不堆砌术语，就用我亲手调通的配置、真实失败的日志、量产线上正在跑的脚本，说清楚一件事：怎么让JFlash真正听懂你的Flash内存结构，而不是把它当成一块黑板随便涂改。
你真了解JFlash在干什么吗？别被GUI骗了
很多人第一次打开JFlash，点开“File → Open data file”，选个hex文件，填个起始地址，点“Program”，看到进度条走完、绿色对勾弹出来，就以为万事大吉。但真相是：JFlash本身从不碰Flash一丁点物理单元。它干的只是三件事：
- 配好MCU的“交通规则”：比如告诉STM32H7，“你Flash控制器的等待周期设成2，ACR寄存器第9位要置1，KEYR先写0x45670123再写0xCDEF89AB”；
- 把一段小程序（Flash算法）塞进MCU的RAM里运行：这个小程序才是真正的“擦写工人”，它知道怎么发命令给Flash控制器、怎么等BUSY位清零、怎么校验一页是否写成功；
- 对工人下指令：“去0x08020000~0x080A0000这段干活，先擦，再写，最后对着比一遍”。
所以当你看到Error: Flash loader reported error (0x0001)，根本不是JFlash错了，是那个在MCU RAM里跑的小程序报的错——它可能因为时钟没配稳、供电电压偏低、甚至Flash控制器被别的外设锁住了，一句话：“这活儿我干不了”。
✅经验第一条：每次换芯片型号或升级JFlash版本，第一件事不是烧程序，而是跑一次
Target → Connect，确认Log窗口里打出Connected to device 'STM32H743VI'且没有Warning: Clock not stable。
更关键的是，JFlash永远按扇区擦除。什么叫扇区？不是你链接脚本里写的.text : ORIGIN = 0x08020000, LENGTH = 0x80000，而是芯片手册白纸黑字印的物理划分。比如STM32H743的主Flash，前8个扇区各32KB，后面全是128KB一档。如果你的.text段横跨了0x0803FFF0~0x08040010，那么哪怕只改了一个字节，JFlash也必须把0x0803E000~0x0804FFFF整个128KB扇区全擦掉——它没得选，硬件就这么设计的。
✅经验第二条：在Keil/IAR/GCC链接脚本里，所有Section的
ORIGIN必须严格对齐扇区边界！用arm-none-eabi-objdump -h your_app.elf检查，.text起始地址末三位必须是000（4KB对齐）、0000（64KB对齐）或00000（128KB对齐），具体看你的MCU手册。
分段烧录不是功能开关，而是一套内存主权声明
“分段烧录”这个词听起来很技术，其实它的本质特别朴素：告诉JFlash，“这块地归谁管，擦不擦、怎么擦、写什么，我说了算”。
默认情况下，JFlash拿到一个BIN文件，就默认它要覆盖从起始地址开始的一整块连续空间。但现实中的固件早就不这么简单了：
- Bootloader放在0x08000000，它负责验签、解密，一旦损坏整车变砖，必须永久保护；
- Application放在0x08020000，这是OTA升级的主力，可以擦可以写；
- NV参数在0x081A0000，存的是车辆VIN、校准系数，出厂写一次，之后只读不擦；
- 密钥区在0x081F0000，硬件级写保护，连MCU自己都只能写一次。
这些区域混在同一片Flash里，就像一栋楼里有金库、办公室、档案室和员工宿舍。你不能因为要给办公室换地毯，就把金库门炸开、把档案烧掉、把宿舍拆了重建。分段烧录，就是给每个房间贴上明确的门牌和使用规则。
看懂这一段配置，胜过十页手册
下面这份.jflash文件片段，是我们现在产线上每天跑5000次的真实配置（已脱敏）：
[Settings] Device = STM32H743VI Interface = SWD Speed = 4000 ResetType = 2 ; Core reset, not system reset [Segments] ; Bootloader: 128KB, 永远只更新，绝不擦除旧版（防回滚攻击） Segment0 = "bootloader_signed.bin", 0x08000000, 0x20000, None, Compare ; Application: 1.5MB, OTA主力，每次更新必须擦对应扇区 Segment1 = "app_encrypted.bin", 0x08020000, 0x180000, Sector, Compare ; 校准参数：出厂写入，后续只读，地址必须扇区对齐（0x081A0000 = 128KB * 21） Segment2 = "calib_default.dat", 0x081A0000, 0x8000, None, Compare ; 安全密钥：硬件写保护，烧录前需解锁FLASH_OPTCR寄存器 Segment3 = "key_derived.bin", 0x081F0000, 0x1000, None, Compare [Verification] VerifyAll = Yes VerifyMode = Compare ; 对于内部Flash，Compare最可靠 Timeout = 30000 ; 校验超时设为30秒，避免SPI抖动误判 [PostFlash] ; 烧录完成后自动执行：跳转到Application入口，验证是否能跑 RunCommand = "mem32 0x08020000" RunCommand = "g 0x08020000"重点看Segment0和Segment3的Erase=None。这不是偷懒，是硬性要求——JFlash会跳过擦除步骤，直接尝试编程。如果该地址已被硬件写保护（比如FLASH_OPTCR的nWRP位锁死了0x081F0000~0x081FFFFF），JFlash会立刻报错Error: Flash programming failed at address 0x081F0000 (Write protected)。这时你就知道：要么密钥区真的被锁死了（符合预期），要么你忘了在烧录前执行解锁命令（需要在[PreFlash]里加ExecCommand = "w32 0x52002014 0x00000000"这类操作）。
✅经验第三条：永远把
Erase=None的段放在配置文件最前面。JFlash按顺序执行，如果前面的段烧录失败（比如密钥区写保护未解除），后面的段根本不会启动，避免“半截烧录”导致系统不可用。
车载T-Box实战：当QSPI遇上分段烧录
我们用的i.MX RT1176有点特殊：它把主程序放在内部Flash（1MB），但日志、地图缓存、音频资源全扔在外置QSPI Flash里（64MB）。这就带来新问题：JFlash默认只认内部Flash算法，不认识QSPI。
解决方法不是放弃，而是“骗”它——用[Device]节区手动注入QSPI初始化流程：
[Device] Name = "i.MX RT1176 QSPI" CPU = "Cortex-M7" FlashBank0 = "Internal Flash", 0x00000000, 0x100000, "algorithms/RT1176_Internal.jflash" FlashBank1 = "QSPI Flash", 0x30000000, 0x4000000, "algorithms/RT1176_QSPI.jflash" [Segments] ; 内部Flash段（同前） Segment0 = "bootloader.bin", 0x00010000, 0x20000, Sector, Compare Segment1 = "app.bin", 0x00030000, 0x100000, Sector, Compare ; QSPI段：注意地址是0x30000000，不是0x00000000！ Segment2 = "map_cache.bin", 0x30000000, 0x200000, Sector, Checksum这里有两个致命细节：
- QSPI段的
VerifyMode=Checksum：如果用Compare，JFlash要把64MB数据全读回PC比对，网络一抖就超时。改成Checksum，由QSPI Flash算法在MCU端算CRC32，只传4个字节回来，稳如老狗； - QSPI段的
Address必须是映射后的地址：i.MX RT1176通过FlexSPI控制器把QSPI空间映射到0x30000000~0x33FFFFFF，你填0x00000000是绝对不行的——JFlash会试图往内部Flash的0地址写，结果当然是Access violation。
✅经验第四条：外置Flash烧录前，务必用
JLink Commander手动执行一次QSPI初始化命令，确认能读出JEDEC ID。我的固定流程是：JLink> exec SetRTTAddr = 0x20000000 JLink> mem32 0x402A0000 1 // FlexSPI1_STAT寄存器，看是否busy JLink> mem32 0x402A0010 1 // FlexSPI1_LUTKEY，写0x5AF05AF0解锁 JLink> mem32 0x402A0014 1 // FlexSPI1_LUT0，查LUT表是否加载成功
那些没写在手册里的坑，我都替你踩过了
坑1：校验通过，但设备死机？检查VerifyMode和Timeout
某次升级后，JFlash日志显示Verification passed，但设备复位后卡在HardFault。抓取CoreSight发现，SCB->ICSR的VECTACTIVE是0，说明根本没进中断向量表——.isr_vector段没写进去。
查原因：.isr_vector定义在0x08000000，但我们配置的Segment0起始地址是0x08000000，长度0x20000（128KB），看起来没问题。但实际.isr_vector只有1KB，其余127KB全是Padding。JFlash的Compare校验，会把这127KB的Padding也读回来比对。而Padding区在Flash里是随机值（擦除后为0xFF，但编程时没覆盖），导致校验失败，JFlash却没报错——因为VerifyAll=Yes只保证“所有段都校验了”，不保证“校验都通过了”。
✅解法：把.isr_vector单独拎成一段，长度精确到字节，并开启VerifyMode=Compare；Padding区用Fill命令在生成BIN时填0x00，确保可预测。
坑2：售后重刷Application，NV参数却变了？
产线同事反馈：只刷app.bin，但车辆VIN码被清空了。查nv_default.dat的地址是0x081A0000，配置里明明写了Erase=None。
深入一看，app.bin的链接脚本里，.data段的LOADADDR被错误设成了0x081A0000（应该用0x20000000RAM地址）！结果JFlash烧录时，把app.bin的.data初始化数据，一股脑写进了NV参数区……覆盖了VIN。
✅解法：所有非Flash段（.data,.bss,.stack）的LOADADDR必须指向RAM，绝不能指向Flash地址！用readelf -l your_app.elf | grep LOAD交叉验证。
坑3：CI流水线里烧录失败，本地却一切正常？
Jenkins服务器用Linux版JFlash，而开发机是Windows。某次构建后，JFlash报错Error: Could not open file 'app.bin'。
查路径：配置里写的是Segment1 = "build/app.bin", ...。Linux下路径分隔符是/，Windows是\，但JFlash跨平台兼容，这不该是问题。再查权限：build/app.bin在Jenkins里是root用户生成，但JFlash进程以jenkins用户运行，没读权限。
✅解法：在Jenkinsfile里加一步chmod 644 build/app.bin；更彻底的是，在.jflash里用绝对路径/var/lib/jenkins/workspace/tbox/build/app.bin，并确保JFlash进程有访问权限。
最后一点实在话：分段烧录不是终点，而是起点
写这篇文章时，我翻出了三年前的项目笔记，那时我们还在用JLinkExe -If SWD -Speed 4000 -CommanderScript program.jlink一条命令走天下。现在，我们的产线烧录站已经进化成这样：
- Python脚本根据车型ID、ECU版本号、产线工位号，动态生成
.jflash配置； - 每次烧录前，自动调用
arm-none-eabi-readelf -s检查符号表，确认__vector_table地址正确； - 烧录后，通过SWO输出
BOOT_STATUS=0x12345678，用串口监听验证跳转成功； - 所有日志实时上传至ELK，支持按
Timestamp、SerialNumber、SegmentCRC全文检索。
分段烧录教会我的，从来不只是怎么填几个地址和参数。它让我真正看懂了那句常被忽略的话：“嵌入式开发，是软硬件之间一场精密的共舞。”
JFlash是指挥家，MCU是乐手，而你的链接脚本、Flash布局、擦除策略，就是那份乐谱——少一个音符，整支乐队就会走调。
如果你也在产线或实验室里，为一个烧录失败的日志抓耳挠腮，欢迎在评论区甩出你的jflash.log片段。我们可以一起，一行行看下去，直到找到那个被忽略的0x00000000地址、那个没对齐的扇区、或者那个被写保护锁死的密钥区。
毕竟，让设备可靠启动的，从来不是工具，而是工程师脑子里那张清晰的Flash地图。
