1. 为什么我要把固件和Option Bytes塞进同一个hex1.1 先聊聊STM32U5G9这颗片的调性STM32U5系列是ST家主打超低功耗和安全性的一代产品STM32U5G9更是这一系里的高配型号Cortex-M33内核带着TrustZoneFlash容量做得很大跑各种带安全要求的应用很合适。做这个项目之前我本来以为它跟以前的STM32L4、F4差不多无非是多配几个低功耗模式结果真正上手才发现这颗片子的玩法跟传统STM32有明显区别——很多东西不是你写好固件下载进去就完了芯片的启动、调试、存储保护全都要看Option Bytes里的配置。尤其当你要把代码交给产线批量烧录或者发给外面的代工厂做贴片后烧录时只给一个Keil/MDK工程是不现实的产线只要一个文件最好还是单个hex双击或者一句命令行就能写好。“Single .hex Containing Firmware and Option Bytes”这个标题说白了就是干这么一件事把应用程序固件、芯片的Option Bytes配置打包到同一个Intel HEX文件里。烧录器烧这个文件等于一次性完成了程序下载和芯片级配置写入。听起来像是个很小的工程动作但实际落地时涉及hex文件解析、Option Bytes地址范围、烧录工具的识别逻辑、甚至批量产线的脚本化坑不少。1.2 Option Bytes和固件“分家”会带来什么麻烦很多从传统MCU转过来的朋友会有个习惯固件就是一个hex烧进去就完事。STM32U5G9这种带TrustZone和安全特性的芯片明显不能这么随意。比如说读保护RDP如果你想开启Level 1甚至Level 2这不是代码里写一个寄存器值就能搞定的必须通过Option Bytes写入而且写入后整个芯片的行为会变。如果你只把固件给产线不把Option Bytes的配置一起给那产线烧出来的每一批板子保护等级可能是乱的调试口有时候能连、有时候连不上Boot模式也可能是错的后续排查起来非常痛苦。更麻烦的是有些配置是有“不可逆”性质的。比如Option Bytes里的某些保护位一旦被设置到高等级后面想解掉必须执行mass erase整个Flash就清空了。如果你只是口头告诉产线“先烧固件再配置OB配置顺序1234”现场工人一旦点错按钮轻则这块板子的数据全没重则直接把调试口锁死板子变砖。所以最稳妥的做法就是事先把整个镜像一个文件搞定把人为操作的余地降到最低。1.3 单文件打包真正解决的问题把Firmware和Option Bytes合并成一个hex实际解决的不是技术问题是工程交付问题。它让烧录这件事从“多个步骤、依赖操作员经验”变成“一个文件、一个动作”。具体来说有三类场景特别需要它第一是量产产线。产线用的烧录器、自动化治具很多只支持一个文件输入或者操作员只被培训过一种烧录流程。这时候一个合并后的hex就是唯一的交付物所有板子结果一致。第二是外包生产。你把工程发给别人代工时当然不希望对方看到你的源码和配置细节更不希望他们错误地改动Option Bytes。交付一个最终合成好的镜像对方拿到手直接烧技术细节全部封死。第三是现场维护和返修。设备发到现场后出问题技术支持带上一个hex文件就能重新烧录不需要现场记一堆Option Bytes怎么配。这一点在实际售后里特别重要毕竟你没法保证每个技术支持都对STM32U5的OB机制了如指掌。2. 动手前的底料Hex格式和Option Bytes都得吃透2.1 Intel HEX格式三分钟聊明白做合并之前先把hex文件的底子搞清楚。这里说的hex通常指的是Intel HEX格式它不是直接把二进制转成ASCII那么“无脑”而是有结构的文本格式。每一行记录都以冒号开头后面依次是本行数据长度、16位地址、记录类型、数据内容、校验和。记录类型里最常见的三种00表示数据记录指向的是实际烧录内容04表示扩展线性地址记录用它来切换32位地址的高16位01表示文件结束记录。举个例子一行:02000004008000意思就是“这一行有2字节数据地址偏移是0x0000类型是04数据是0x0080这条记录告诉解析器后续数据记录的高16位地址要按0x0080来算”。所以当你在STM32U5G9上做合并时Flash固件在0x08000000区域Option Bytes可能在0x0BFA0A00区域这两个区域跨越了不同的高16位地址段就必须依赖扩展线性地址记录来区分。如果你只是把两个hex文件用记事本粗暴拼到一起不校验地址上下文文件末尾缺少EOF标记解析器可能根本读不完或者把Option Bytes的数据按照0x0800xxxx这个错误地址去烧。很多人在做手动拼接时都会遇到的一个经典报错是“hex文件校验和错误”。这是因为Intel HEX每一行最后一个字节是校验和它要求本行所有字节相加再做二进制补码结果必须为0。你手工改了一行里的数据内容却没有重算校验和那这一行在下载时必然报错。理解了这一点后面无论是写脚本还是用工具处理心里都有底。2.2 STM32U5的Option Bytes存了什么为什么重要Option Bytes在STM32U5系列里简单说就是芯片出厂后仍然可以改的一组“非易失性系统配置”。它和普通Flash用户区最大的区别是Option Bytes有专门的访问机制不能像写一个普通数组那样直接往地址里写它需要通过烧录器或芯片内部接口触发特定的加载和写入流程。U5G9上常见的配置项包括RDP读保护等级也就是Level 0/1/2跟调试口访问、Flash回读权限直接相关BOR欠压复位阈值决定供电跌到多少伏时系统复位TrustZone使能位TZEN没设置前Cortex-M33的安全扩展是关闭的一旦开启后续Flash布局和启动方式都会被改变还有PCROP专有代码保护、WRP写保护、Boot地址选择等。这些配置项在芯片内部存储时很多还带互补字节机制也就是说一个配置位可能有正常值和取反值两个副本芯片启动时会对两个副本做对比发现不一致就直接走默认安全路径。这就意味着如果你手动去改Option Bytes的hex只改了正常值没有同步修改互补副本芯片可能会认为配置已经被破坏然后拒绝加载或者强制回退到某个默认状态。所以我对这类项目一直有一个坚持Option Bytes的hex内容尽量从STM32CubeProgrammer等官方工具生成不要靠脑子记偏移量手写。官方工具知道每一版芯片的OB布局和互补字节规则远比我们拿个陈旧表格去手动拼可靠得多。2.3 写Option Bytes的顺序比内容更敏感这里说一个很多人忽略的点Option Bytes不是“想改就能改”的。STM32U5G9的Option Bytes写入通常需要先向寄存器发出解锁序列再写入目标值最后触发一个系统复位让芯片重新加载OB。在这个过程中某些保护位的改变会立即影响当前会话。比如说你一次性把RDP从Level 0改成Level 1芯片在下次复位后就会限制调试口访问如果你设置的是Level 2那么复位后调试口就彻底失效了除非你能通过其他方式触发全片擦除否则这块芯片就永久锁死。在实际合并single hex时这部分体现出来的风险是如果你的固件和OB被合并后烧录器直接按地址顺序写先写了固件、随后写了OB而OB里包含一个会触发Flash擦除的保护位那很可能固件刚写完就被保护位的变化搞掉了。虽然大多数正规烧录工具会识别OB区域并按照厂商推荐的顺序处理但还是要养成一个习惯在合并且烧录后第一步就是回读验证确认固件还能正常启动OB配置确实生效。对于量产板这个验证步骤绝不能省。3. 方案选型合并hex的几种姿势和取舍3.1 方案对比文本拼接、脚本处理、专业工具把固件hex和Option Bytes hex合并成一个文件做法其实有三条路手动文本拼接、写Python脚本、用现成的专业工具比如SRecord。我逐个说下取舍。手动文本拼接是最原始的做法。操作步骤大概是把两个hex文件复制到同一个文件里然后只保留最后一个文件的EOF行。这种做法表面看“好像能跑”实际上隐患很大。Intel HEX解析器从头读到尾依赖扩展线性地址记录来维护当前高16位地址。如果你直接把固件hex和OB hex无脑连在一起第二个hex的开头如果没有重新声明扩展线性地址记录解析器就会继续沿用前一个文件的高地址导致Option Bytes的数据被写到0x0800xxxx这个完全错误的位置。而且手动拼接没法解决两个文件里某些地址段数据意外重叠的问题一旦烧错特别难排查。写Python脚本是半自动的做法也是我这次项目里实际采用的路线之一。脚本可以解析每个hex文件里的每一条记录保留完整的地址信息合并后重新生成一份规范化的Intel HEX还能顺带做校验和验证。它的好处是可控、可重复适合在没有额外工具的环境里快速处理。但脚本需要自己维护尤其要处理好扩展线性地址记录写错了后果比手动拼还隐蔽。用专业工具是最省心的路线。SRecord这个开源工具集里有一个srec_cat专门用来做多种格式的记录文件拼接、裁剪、转换。它对Intel HEX的各种记录类型支持很完整还能做地址重叠检测输出的hex文件格式规整几乎不会出错。唯一的问题是要在电脑上装一个SRecord环境对某些只在Windows下用Keil的工程师来说多了一个学习成本。3.2 合并原理地址分段和扩展记录怎么处理无论用哪种方案合并的原理都一样把两个hex文件里的所有数据记录按照它们解析出来的绝对地址重新排列然后统一输出成一个新的hex文件。这里的关键是正确解析扩展线性地址记录类型04因为只有把它和后续数据记录里的16位地址拼在一起才能得到真实的32位绝对地址。举个例子固件文件里第一条扩展线性地址记录可能是0x0800后面的数据记录地址都是0x0000到0xXXXX那么这条数据实际对应的Flash地址是0x08000000 0xXXXXOB文件里的扩展线性地址记录可能是0x0BFA数据记录地址是0x0A00之类那对应的OB地址就是0x0BFA0A00附近。合并时不能让两个文件的地址上下文互相污染srec_cat和成熟的Python脚本都能做到每个文件独立解析后再统一输出。另一个要处理的问题是数据记录的长度。标准Intel HEX的数据记录长度字段通常为0x10或0x20这种但不同工具生成的文件可能不一样。输出时最好统一成固定长度比如32字节一条因为很多烧录器对过长或过短的数据记录支持不稳定。还有一点合并后的hex文件末尾必须有一个且只有一个EOF记录类型01否则部分解析器会报“文件不完整”的警告。3.3 我最终选的路子这次项目里我并没有只依赖一种方案而是把工具和脚本结合起来了。生成OB模板、验证芯片状态用STM32CubeProgrammer日常合并单个文件用srec_cat因为它在命令行下很好集成到CI或产线脚本同时我自己留了一份Python脚本用来处理一些特殊场景比如产线需要把两个hex合并的同时给特定Flash地址填一段序列号数据。这个组合的好处是正常流程有工具兜底不容易出错特殊需求有脚本可以扩展不会卡住。后面我会把两个路线的具体操作都写出来你可以根据自己环境选。4. 实操STM32U5G9生成Single Hex的全过程4.1 第一步把编译产物导成固件hex做合并前先要有固件hex。如果你用的是STM32CubeIDE编译完成后默认会在输出目录生成.elf但有时候不会自动生成.hex。我一般会通过Post-build steps里加一行命令arm-none-eabi-objcopy -O ihex build/output.elf firmware.hex这行命令会把ELF文件转换成带地址信息的Intel HEX文件。注意不要用-O binary去转因为binary格式不带地址段合并OB时还要手动指定起始地址麻烦。如果你用的是Keil MDK只要在Options for Target - Output里勾选“Create HEX File”编译后就会在Listings目录下生成hex。IAR则在Project - Options - Output Converter里选择Intel extended HEX格式。三种工具链生成的hex在格式上略有差异但只要是标准Intel HEX后续合并都能处理。这里还有一个细节编译产物如果是带Bootloader的复杂工程可能会生成多个段比如0x08000000的Boot区、0x08020000的App区。objcopy转出来的hex会自动包含这些段合并时无需额外处理。但如果你的工程链接脚本里把某个段放在了其他非Flash地址比如外部RAM调试段那生成的hex里也会带上这些地址烧录时可能会报错需要提前在链接脚本里排除掉。4.2 第二步用STM32CubeProgrammer生成Option Bytes hex这是整个项目里最容易让人卡住的一步因为ST官方没有专门提供一个单独的按钮“把当前OB配置存成hex”但实际是可以做到的。我的做法分两种根据情况选。方法A从母板读回。拿一块已经调试好、OB配置正确的板子用STM32CubeProgrammer连接在左侧选择Option Bytes页面确认当前显示的各项内容是你想要的。然后点击工具栏上的Read按钮在读取范围里选择包含整个Option Bytes区域的选项或者直接选择“全片读取”把读出内容保存成一个hex文件。这个hex里既有Flash固件又有OB数据严格说它已经是一个完整的single hex可以直接作为产线黄金镜像使用。方法B如果你不想读取整片Flash只想要OB模板可以先用CubeProgrammer的Option Bytes页面把各项配置好然后寻找页面里的Export/Save按钮把配置导出为.ob文件。不过.ob文件不直接是hex需要再用工具或脚本转换。相对麻烦一点所以我个人更推荐方法A它简单直接而且读回来的OB内容是芯片上真实存在的完整副本包含所有互补字节不容易出错。用CubeProgrammer读取时建议通过SWD接口连接连接前先把板子的复位引脚处理好防止芯片在读取过程中被外部复位打断。如果你要读取的板子已经开启了RDP Level 1Flash区域是读不出来的但OB区域通常还能读具体情况要看芯片状态。对于全新的、还没有设置保护的板子直接读全片是最省事的。4.3 第三步srec_cat一键合并推荐路线拿到固件hex和OB hex后用srec_cat合并是最省心的。假设两个文件分别是firmware.hex和option_bytes.hex命令如下srec_cat firmware.hex -Intel option_bytes.hex -Intel -o merged.hex -Intel这个命令的含义是以Intel HEX格式解析两个输入文件合并后以Intel HEX格式输出到merged.hex。srec_cat会自动解析每个文件内部的扩展线性地址记录并把所有数据按绝对地址重新排序。如果两个文件里有地址重叠的情况srec_cat默认会报错这时你需要先检查为什么会重叠而不是随便加一个强制覆盖参数糊弄过去。合并完成后建议加一步生成一个校验用的列表文件srec_cat firmware.hex -Intel option_bytes.hex -Intel -o merged.hex -Intel -list merged.list-list参数会生成一个文本文件列出合并后hex里每个地址段的起始、结束和总长度。我每次合并都会看一眼这个列表确认固件段在0x08000000附近OB段在OB区域只要两个段都正常出现基本就说明合并成功了。4.4 第三步备选用Python脚本合并并校验如果你不想装SRecord或者需要在合并过程中插入自定义逻辑可以写一个Python脚本。这里我提供一个我自己常用的简化版它做三件事解析Intel HEX、合并两个文件、输出新的Intel HEX并做基本重叠检查。# 合并两个Intel HEX文件firmware.hex option_bytes.hex import sys def checksum(body: bytes) - int: return ((~sum(body)) 1) 0xFF def make_record(addr: int, rtype: int, data: bytes) - str: body bytes([len(data), (addr 8) 0xFF, addr 0xFF, rtype]) data return : body.hex().upper() f{checksum(body):02X} def parse_hex(path: str): records [] upper 0 with open(path, r) as f: for raw in f: line raw.strip() if not line.startswith(:): continue n int(line[1:3], 16) addr int(line[3:7], 16) typ int(line[7:9], 16) data bytes.fromhex(line[9:9 n * 2]) if typ 0x04: upper (data[0] 8) | data[1] elif typ 0x00: records.append(((upper 16) | addr, data)) elif typ 0x01: break return records def write_hex(path: str, records): records.sort(keylambda x: x[0]) cur_upper None with open(path, w) as f: for abs_addr, data in records: upper (abs_addr 16) 0xFFFF if upper ! cur_upper: f.write(make_record(0, 0x04, bytes([upper 8, upper 0xFF])) \n) cur_upper upper f.write(make_record(abs_addr 0xFFFF, 0x00, data) \n) f.write(make_record(0, 0x01, b) \n) if __name__ __main__: fw parse_hex(firmware.hex) ob parse_hex(option_bytes.hex) combined fw ob # 检查重叠如果同一绝对地址出现多份数据说明有问题 addr_count {} for abs_addr, data in combined: addr_count.setdefault(abs_addr, 0) addr_count[abs_addr] 1 dup [a for a, c in addr_count.items() if c 1] if dup: print(fWARNING: overlapping addresses: {dup[:10]}) write_hex(merged.hex, combined)这个脚本不算长但已经能解决90%的日常合并需求。它有两个关键点一是解析类型04记录把高16位地址存下来二是输出时统一为32字节数据记录、重新生成校验和。如果你后续还要在合并时插入序列号或者修改某段数据这个脚本就是很好的改造起点。4.5 第四步合并结果的验证与烧录合并完成不代表万事大吉必须做一次验证。我通常先用文本编辑器或者命令行工具查看合并后的hex确认文件末尾确实只有一个EOF记录确认OB区域的地址段还在。更严谨的做法是用objcopy把hex转成bin再按地址裁剪分别比对固件段和OB段是否与源文件一致。验证无误后用STM32CubeProgrammer烧录。命令行方式如下STM32_Programmer_CLI -c portSWD modeUR -d merged.hex -v -rst-v启用校验-rst烧录完成后复位芯片启动。烧录时CubeProgrammer会识别hex里的Flash地址和OB地址并对OB区域做特殊处理。这里我要提醒一句如果你用的烧录器不是STM32CubeProgrammer而是第三方工具一定要确认它是否支持火焰地识别OB地址范围。少数工具会尝试把OB地址当成普通Flash地址去写结果自然是失败。烧录完成后再次连接芯片进入Option Bytes页面查看实际生效的配置确认RDP、BOR、TrustZone等关键项和预期一致。有时候OB写入后需要重新上电才生效所以我在验证时一般会先断开连接给板子断电再上电然后再读OB确保看到的是真实状态。5. 量产脚本化把Single Hex流程固化到产线5.1 命令行一键生成如果只是一次性交付手动合并就够了。但量产项目里固件版本会迭代每次编译都要重新生成一次single hex所以我会把整个流程写成一个批处理脚本或Makefile目标。核心逻辑就是三部曲编译生成固件hex、从固定位置拿OB模板、srec_cat合并输出带版本号的文件。比如Windows下可以写一个简单的批处理echo off srec_cat firmware.hex -Intel option_bytes.hex -Intel -o merged_v1.2.hex -Intel固件文件名里的版本号建议从构建系统里动态取不要在脚本里写死。每个版本生成后我还会顺手生成一个SHA256哈希值保存下来方便后面追溯到底烧到产线的是哪个文件。这一步在审核审计时特别有用因为产线操作员可能并不清楚自己烧的是不是最新版但哈希比对能一锤定音。5.2 版本管理和文件命名规范single hex一旦变成产线交付物它就不仅仅是技术文件了而是受控资产。我的习惯是把它和固件源码、链接脚本、OB配置文件放在同一个发布目录文件夹里必须有一份README说明这个版本的固件是基于哪个commit编译的OB模板是由哪块母板导出的合并且烧录验证过哪几块样机。文件命名上我建议包含产品型号、固件版本、OB版本、日期。比如U5G9_App_v1.2_OB_20250612.hex。这样无论文件流转到谁手里单看文件名就知道它是什么、什么时候生成的。不要用final.hex这种名字我曾经就在产线文件夹里见过三个不同日期的final.hex那种混乱程度足够让人崩溃。5.3 产线烧录时注意OB段识别量产烧录时烧录器软件对OB段的识别是个容易被忽略的点。STM32CubeProgrammer在这一块做得比较好能识别standard的OB地址并自动走Option Bytes烧写流程。但如果你用的是J-Flash或者某些国产烧录器它们对OB地址的识别逻辑各不一样。有的需要你在配置里手动把OB地址段标注出来有的则要求把OB数据放到特定位置才能识别。最稳妥的做法是在正式量产前拿几块测试板用产线同款烧录器和同款single hex完整走一遍流程然后读回OB配置确认无误。和研发环境不同产线烧录讲究的是“傻瓜化”和“一致性”宁可在试产阶段多花半天验证也不要等量产到一半才发现烧录器根本没写OB。6. 实战中踩过的坑与排查速查6.1 别让地址重叠毁掉你的hex合并hex时最容易出现的一个隐蔽错误是地址重叠。固件文件和OB文件理论上不可能冲突但有时候OB模板是从旧型号或不同子型号芯片上导出的OB区域偏移会不一样有时候固件工程的链接脚本把某个段放到了保留地址区结果恰好覆盖了OB区域。这种重叠不会让合并工具直接报错但烧录后轻则配置没生效重则启动异常。我的排查方法很“土”但很有效合并后用srec_cat -list或Python脚本把每个数据段打印出来肉眼扫一遍起始地址。看到0x08000000开头的段是固件0x0BFA开头的段是Option Bytes两者井水不犯河水就可以放心。千万不要跳过这一步尤其是OB模板换过之后。6.2 保护位设置不当芯片直接变砖这个坑本来是做OB配置时最该警惕的放到single hex场景里变得更加隐蔽。因为你面对的不再是一个“当前工程配置”而是一个已经写死的OB镜像如果你没有记录清楚这个镜像里RDP设的是哪一级烧到某块板子上发现调试口连不上可能已经晚了。我的建议是所有OB模板文件里必须标明RDP等级。如果模板的RDP是Level 1或Level 2在量产烧录前一定要和客户、产线确认清楚这块板子后续还允不允许研发读回Flash。尤其是Level 2一旦烧入芯片的调试口永久关闭没有任何办法在系统层面解除。如果你只是想在研发阶段自己测试千万不要把Level 2保护做进模板里否则会有整批板子报废的风险。6.3 校验和、扩展地址记录出错的典型表现我自己刚写Python合并脚本时曾经犯过一个很典型的错误输出hex时没有正确维护扩展线性地址记录导致OB段的数据被写到0x0800xxxx区域。烧录时不报错但是烧完读回发现Option Bytes完全没生效重复烧录了几次才发现问题。这类错误的表现通常有三个烧录工具提示地址越界、校验和错误、或者烧录成功但OB配置没变化。排查时先看hex里是否有正确的类型04记录再看每行数据的校验和是否一致。用srec_cat合并基本不会出这种问题但如果你用了自己的脚本务必用工具校对一次不要迷信自己写的代码。6.4 从旧板卡“克隆”完整hex的正确姿势有时你会遇到一个需求手里有一块能跑的旧板子想把它的完整配置克隆出来备份或者复制到其他板子上。这种需求里最忌讳的是只读Flash区忽略Option Bytes。很多工程师对STM32U5G9不熟悉以为读回0x08000000的Flash就等于备份了全部结果换了一块新片烧进去发现芯片启动行为不对因为OB里没有同步设置TrustZone、读保护等。正确姿势是在CubeProgrammer里用整片读取也就是把Flash、OTP、Option Bytes都读出来保存为hex。这样得到的文件天然就是一个single hex包含了所有非易失状态。注意如果原板已经开了RDP保护这个方案会读不到Flash内容所以“克隆”操作最好在保护开启之前做或者使用官方允许的方式先解除保护。6.5 常见问题速查表现象可能原因排查/处理建议合并后hex烧录工具报校验和错误手动修改某行数据后没有重算校验和用srec_cat重新生成或用objcopy重新转换OB段没有被写入旧烧录器不识别0x0BFA0A00区域确认烧录器版本换用STM32CubeProgrammer烧录后RDP配置不生效OB模板读自错误型号或OB地址偏移错误重新从母板导出OB模板核对型号芯片调试口无法连接RDP Level 1或Level 2已激活确认模板保护等级必要时使用STM32CubeProgrammer复位选项合并后固件启动异常固件和OB地址重叠用列表工具检查段起始地址读回的全片hex里没有OB数据读回时未包含OB区域使用整片读取或单独读取OB区域最后分享一个我自己的习惯每次准备好一个量产用的single hex我都会先烧到一块新片子上然后立刻读回整个Flash和OB配置跟源文件做一次逐字节比对。这个习惯从STM32F4时代一直保留到现在救了我很多次。无论是合并脚本出bug、OB模板选错还是烧录工具版本不一致都能在最早的阶段暴露出来而不是等到产线反馈才手忙脚乱。