1. 为什么嵌入式开发离不开srec_cat这类格式工具先聊个场景。你用Keil或STM32CubeIDE编译完固件默认生成的是.hex文件烧录、OTA升级、量产下载很多时候需要的却是.bin。更麻烦的是当你同时维护Bootloader和App两个工程想要把两份固件合成一个镜像直接扔给产线烧录器Hex文件那套寻址规则反而成了绊脚石。我最早遇到这个问题是在做批量产测时。当时产线只认.bin而我手里的固件都是.hex试过用Keil自带的fromelf转能转但只能整个转没法只截取其中一段更没法把两个固件拼在一起。后来换成J-Flash也能转但是图形界面操作每换一个版本就要手动点一遍实在太浪费时间。srec_cat就是在这种背景下进入我视野的。它是SRecord工具集里的核心命令行工具专门用来处理嵌入式固件的各种格式Intel HEX、Motorola S-Record、二进制BIN、Tektronix等等。它最值钱的地方不是简单的格式互转而是对固件数据块的裁剪、拼接、偏移、填充和校验能力而且全部可以用一行命令完成随便放进脚本和CI流水线。这篇内容不打算写手册我梳理了日常实战中最常见的5种用法全程带上STM32的示例命令每个用法都会讲清楚为什么这么用、命令参数背后在干什么、有哪些坑不能踩。很多细节是网上文档不会写、只有踩过坑才明白的放出来供你参考。2. 动手前置srec_cat的安装、命令结构和工作原理2.1 安装方式与跨平台使用SRecord是一套开源工具支持Windows、Linux和macOS安装相当省事。Windows环境下直接去SRecord官网下载对应平台的压缩包解压后把bin目录加入系统PATH即可。我一般习惯把srec_cat.exe、srec_info.exe、srec_cmp.exe这几个文件单独拷到一个tools目录方便在工程里统一管理版本。Linux环境下更简单Debian/Ubuntu系直接敲以下命令sudo apt install srecordmacOS用Homebrew安装brew install srecord装完后在命令行输入srec_cat -Version验证一下能输出版本号就说明环境到位了。2.2 理解srec_cat的命令行结构srec_cat的命令格式初看有点绕但拆开来说其实就三步输入文件输入格式、中间处理操作、输出文件输出格式。每个环节都用独立的参数块表达多个输入文件就依次列出处理操作按顺序叠加。srec_cat [输入文件] [输入格式] [处理操作...] -o [输出文件] [输出格式]拿最简单的HEX转BIN举例srec_cat firmware.hex -intel -o firmware.bin -binary这一行的意思是读取firmware.hex文件告诉工具它的格式是Intel HEX-intel参数然后输出到firmware.bin格式是纯二进制-binary参数。这里最关键的一点是所有操作都是基于地址空间进行的。srec_cat内部会把输入文件解析成一条条带地址的数据记录后续的crop、offset、fill操作全都在这个抽象的地址空间里进行最后输出时才按照目标格式重新编码。这也是它比直接改文件字节流灵活得多的原因。2.3 一个容易理解偏了的概念HEX与BIN的本质区别很多新手会把HEX和BIN理解成两种不同的文件格式其实更准确的说法是两种不同的数据表达方式。HEXIntel HEX本质上是文本文件每一行记录包含地址、数据长度、数据和校验和专门用来解决“数据应该放在哪个地址”的问题。BIN则是纯二进制从文件第一个字节开始连续存放数据本身不携带任何地址信息烧录时默认按顺序从起始地址写入。这个区别直接决定了srec_cat的很多行为逻辑。比如HEX转BIN时如果HEX文件里有两个不连续的地址段那么两个段之间的空隙在BIN文件里会以空数据占位后面会详细说填充策略而BIN转HEX时因为没有地址信息必须通过-offset参数指定一个起始地址否则工具不知道把数据映射到哪个地址空间。3. 五个高频实战场景从转格式到固件合并一次讲透3.1 基础操作HEX转BINOTA和烧录的必经之路HEX转BIN是出现频率最高的需求。Bootloader做OTA升级时APP固件通常以BIN格式下发到MCU内部Flash因为BIN体积小、解析简单不需要MCU再去做HEX文本解析。量产烧录场景很多烧录器对BIN的兼容性也更好。基础命令只剩一行srec_cat firmware.hex -intel -o firmware.bin -binary但这里有一个隐藏考点HEX文件里的地址不是从0开始的。以STM32为例固件起始地址通常是0x08000000那么转换出来的BIN文件开头就会填充0x08000000个字节的空数据文件体积可能是固件实际大小的几十倍。这就引出了srec_cat第一个高频配合参数-offsetsrec_cat firmware.hex -intel -offset -0x08000000 -o firmware.bin -binary-offset -0x08000000的含义是把整个地址空间向左平移0x08000000让固件数据从0地址开始排列这样生成的BIN文件体积就和实际固件体积完全一致了。负号表示向左偏移正数表示向右偏移这个正负号经常有人搞反转换完发现文件变大几万倍基本都是这个原因。3.2 地址段裁剪只要APP不要Bootloader做OTA或者调试时经常遇到一个HEX文件里同时包含多个地址段的数据。最常见的就是Bootloader工程生成的HEX里面既有0x08000000开始的Boot区代码又有0x0801F000之类的配置信息区。但实际要烧录或分析时往往只需要其中一段。-crop参数就是干这个的格式如下srec_cat full.hex -intel -crop 0x08000000 0x0800FFFF -o bootloader.bin -binary这行命令的意思是只保留0x08000000到0x0800FFFF这段地址范围内的数据范围之外的直接丢弃。配合-offset使用可以顺便把地址归零srec_cat full.hex -intel -crop 0x08010000 0x0803FFFF -offset -0x08010000 -o app.bin -binary上面这条命令就把0x08010000到0x0803FFFF这个区间的APP固件提取出来并且把起始地址平移到0生成一个干净的APP镜像。这里有个需要注意的细节-crop后面的结束地址是不包含在数据范围内的。也就是说-crop 0x08000000 0x08010000截取的是0x08000000到0x0800FFFF这64KB空间如果写错成0x08000000 0x08000001只取1个字节想要2个字节写成0x08000000 0x08000002。这个左闭右开的区间逻辑和C语言数组下标一致但人是很容易习惯性写错的我至少见过三个同事在这里翻过车。3.3 多固件合并Bootloader和App一次烧录量产场景最爽的用法来了。STM32芯片出厂后Flash是空的产线烧录时如果Bootloader和APP分成两个文件烧就要烧两次、切两次配置时间成本翻倍。如果生产量到了几十K的量级每片多出来的几秒钟都是白花花的银子。用srec_cat可以把Bootloader和APP合成一个镜像文件srec_cat boot.hex -intel app.hex -intel -o combined.bin -binary两个输入文件依次给出工具会自动按照各自的地址信息排列数据最终生成一个完整的BIN镜像。Bootloader占0x08000000到0x0800FFFFAPP占0x08010000到0x0803FFFF合并后的BIN天然就是连续完整的固件。但如果你直接跑这条命令合并且不关心地址空洞的话生成的BIN文件体积很可能是0x08040000字节——大约是4MB。原因前面讲过BIN没有地址信息从0地址开始排而两个输入文件的数据都在0x08000000以上的区间低地址段全部是空洞。所以工程化的合并命令长这样srec_cat boot.hex -intel app.hex -intel -offset -0x08000000 -o combined.bin -binary把整个地址空间平移0x08000000后BIN文件从偏移0开始就是Bootloader紧跟着是APP文件体积等于两个固件实际大小之和干净利落。要是合并时两个文件有相同地址段的数据重叠srec_cat会直接报错提示Address overlap。这是它的默认保护机制防止固件数据互相覆盖。如果你确实需要让后者覆盖前者可以加-overwrite参数。但实际项目中我很不建议用这个参数因为它会掩盖地址分配的bug宁可让构建脚本报错也不要悄悄覆盖。3.4 地址偏移OTA固件分区的动态调整有时候同一个固件需要放到不同的Flash地址运行。最常见的场景是Bootloader从1.0升到2.0APP预留的地址段变了或者同一套代码需要适配两个不同Flash布局的板型。这种场景直接用-offset重定位srec_cat app.hex -intel -offset 0x00010000 -o app_relocated.hex -intel这行命令把app.hex所有数据的地址整体向右平移0x1000064KB生成新的HEX文件。在Bootloader里跳转地址相应改成0x08010000配合修改向量表偏移STM32的SCB-VTOR寄存器就能正常启动。用-offset时要注意如果固件里用了绝对地址寻址比如直接操作某个外设寄存器的指针、绝对跳转、直接在链接脚本里写死了地址平移之后运行时会出问题。因为地址平移改的是数据的存放位置不会自动改代码里的立即数。好在STM32的Cortex-M内核指令大多基于PC相对寻址重定位后能正常工作但涉及中断向量表、分散加载文件这些内容时必须手动同步修改VECT_TAB_OFFSET即SystemInit或者main函数里设置的SCB-VTOR值和链接脚本的FLASH起始地址。忘了改VTOR算是这个用法最经典的翻车点症状是程序下载成功但一运行就死机。3.5 校验计算为OTA固件加一道保险做OTA最怕固件传输过程中损坏下载完成了一校验发现数据不对设备直接变砖。常见的方案是在固件末尾附加CRC32或者SHA256校验值Bootloader启动前计算整个固件的校验和文件末尾附加的校验值对比一致才允许跳转执行。srec_cat可以做两件事一是给固件算校验值并自动附加到文件末尾二是直接查看固件的哈希结果。给固件附加CRC32校验的命令如下srec_cat app.hex -intel -crc32-b-e 0x08010000 0x0803FFFF -o app_with_crc.hex -intel这里的-crc32-b-e参数意思是对0x08010000到0x0803FFFF这段地址的数据计算CRC32校验值然后把校验结果以大端-b格式放在这段地址的末尾-e。Bootloader收到固件后先从整包计算出CRC32再和末尾存放的校验值比对就能确定固件是否完整。如果只是想在构建时确认一下固件哈希直接用-sha256参数srec_cat application.bin -binary -sha256工具会在终端直接输出SHA256哈希值配合CI流水线在发布固件时自动生成哈希文件方便后续追溯。校验和计算有一堆衍生参数-crc32-b-e、-crc16-b-e、-sha256、-md5等。需要注意算法字节序问题。比如CRC32算出来是4个字节大端还是小端存放必须和Bootloader端解算逻辑保持一致否则两边数值对不上。我自己就吃过亏工具原厂默认是little-endianBootloader里用的又是大端解析查了一下午才发现是字节序搞反。4. STM32实战一条命令完成量产镜像构建4.1 场景设定与前置条件假设一个STM32F103项目Flash共512KB布局如下分区地址范围大小内容Bootloader0x08000000 - 0x0800FFFF64KB引导程序负责OTA升级APP0x08010000 - 0x0803FFFF192KB应用程序业务逻辑参数区0x08040000 - 0x0807FFFF256KB运行参数、日志存储工程构建需要自动完成两个任务一是生成用于量产烧录的合并镜像二是生成一个带CRC校验的OTA升级包。4.2 生成量产合并镜像在Makefile或者构建脚本里写这样一段# 将Bootloader和APP合并为量产烧录镜像 srec_cat \ build/bootloader.hex -intel \ build/application.hex -intel \ -offset -0x08000000 \ -o dist/production.bin -binary # 生成对应的烧录日志文件方便追溯 srec_cat build/bootloader.hex -intel build/application.hex -intel \ -offset -0x08000000 \ -o dist/production.hex -intel这里同时生成了BIN和HEX两个版本。产线如果用J-Flash或者ST-Link批量烧录HEX格式自带地址信息更保险如果是串口ISP或者自制烧录器用BIN直接烧录production.bin即可。注意我在第一个命令里加了-offset -0x08000000这是为了Trim掉BIN文件开头的大段空洞。不加这个参数生成的BIN文件会从0地址开始包含0x08000000字节的空数据文件体积直接变成128MBFlash再大也装不下产线烧录直接卡死。4.3 生成带CRC校验的OTA升级包OTA升级包和数据烧录镜像不同它不需要Bootloader区只需要APP区的固件加上末尾校验让Bootloader能够单独处理这个包# 裁剪出APP区加上CRC32校验大端格式附加在末尾 srec_cat build/application.hex -intel \ -crop 0x08010000 0x0803FFFF \ -crc32-b-e 0x08010000 0x0803FFFF \ -offset -0x08010000 \ -o dist/app_ota.bin -binary关键点拆解第一步crop只保留APP区数据第二步crc32-b-e对原始地址范围内的数据计算CRC32并放在固件末尾第三步offset把整个数据平移回0地址方便OTA升级时固定偏移量写入Flash。Bootloader端的校验逻辑就是标准的逐字节计算CRC32然后与包尾4字节对比。如果APP大小不定Bootloader不知道具体校验范围可以在固件包里额外定义一个头部结构体记录版本号、固件长度、CRC值这样升级逻辑更健壮。4.4 把srec_cat固化进构建流程单次命令没啥可说的但这东西真正的价值在于自动化。我自己在CI流水线里加了两个Job第一个Job负责构建三个固件变体Debug、Release、OTA每个变体都会调用srec_cat生成对应的BIN、HEX以及SHA256校验文件。第二个Job负责上传产物时附带完整的构建信息包括编译时间、Git提交号、各个固件的哈希值。这样每次点击“发布”按钮产线和技术支持拿到的就是一个自包含的发布包不会出现“这个BIN是哪个版本编译的”这种千古之谜。5. 踩坑实录srec_cat使用中的典型问题排雷5.1 “Address out of range”报错原因没那么简单这个报错初学者经常碰到但原因往往不是真的地址越界。最常见的两种情况一是输入文件本身地址范围比较小但你在-crop时给了一个超大的目标范围二是输入文件地址范围重叠工具检测到数据冲突。排查方法很简单先用srec_info查看文件实际的地址范围srec_info firmware.hex -intel输出里会明确列出起始地址、结束地址、数据块数量。对照一下你的-crop或者-offset参数基本一眼能看出问题。5.2 BIN文件体积异常庞大转BIN后发现文件有几十MB甚至几百MB十有八九是地址没有归零。这既可能是忘了加-offset也可能是offset正负号写反了。用一条命令可以快速确认srec_info output.bin -binary查看输出的起始地址如果显示0x08000000而不是0x00000000那说明开头的大段空洞还在。加上-offset -0x08000000重新生成即可。5.3 合并固件后设备无法启动合并生成的镜像烧进芯片后直接死机优先排查中断向量表VTOR、链接脚本的Flash起始地址、以及跳转地址三者是否一致。这个坑在3.4小节已经详细说明操作手法上的建议是每次修改Flash分区布局后全局搜索工程里所有涉及0x08000000或VTOR的代码全部统一改完再编译。5.4 CRC校验值对不上两边算法一致但结果对不上时先看字节序。Bootloader的CRC实现可能是软件查表法也可能是硬件CRC外设计算方式本身要统一。另一个隐性坑是CRC计算范围不包含固件末尾附加的CRC本身。如果你把整个文件包括追加的CRC都算进去那结果自然是错的。5.5 常见问题速查表现象可能原因排查方法转出的BIN体积巨大地址未偏移回0srec_info查看起始地址合并时提示重叠两个文件地址段交叉查看两个文件的实际地址范围offset后程序死机VTOR或链接脚本未同步检查SCB-VTOR设置和ld文件CRC对不上字节序或计算范围不对确认大小端并排除CRC自身字节文件被“截断”crop范围写错左闭右开核对结束地址是否多写/少写1字节6. 拓展用法srec_cat在工程化体系中的搭档工具6.1 配套工具各有分工SRecord工具集不止srec_cat一个成员。srec_info用来查看文件信息srec_cmp用来对比两个文件是否一致srec_unalias用于去除重复数据srec_sort把数据块按地址排序各有各的用途。我自己常用的配套组合是构建后用srec_info确认固件布局正确发布前用srec_cmp对比两个版本差异用srec_cat算SHA256做完整性验证。这几个工具全部可以整合进脚本产线上发生固件问题时登录构建服务器跑一遍就能定位是哪个环节出了问题。6.2 与其它格式处理工具的互补srec_cat擅长的是处理地址空间和格式转换但它不擅长修改二进制内容本身。如果你需要给BIN文件打补丁、修改某个特定偏移的字节用xxd或者python脚本处理更顺手。组合玩法也很简单先用srec_cat把HEX裁剪成指定地址段的BIN再用python读取BIN文件修改指定偏移的数据最后用srec_cat把修改后的BIN重新转回HEX附加上正确的校验值。这一套流程特别适合做固件配置参数注入比如给每个设备烧录前写入唯一的MAC地址或序列号。6.3 关于Makefile中集成的小建议如果在Makefile里集成srec_cat建议用变量统一管理参数SREC_CAT srec_cat APP_BASE 0x08010000 APP_SIZE 0x00030000 ota_package: $(SREC_CAT) build/application.hex -intel \ -crop $(APP_BASE) $(shell printf 0x%08X $$(($(APP_BASE)$(APP_SIZE)))) \ -crc32-b-e $(APP_BASE) $(shell printf 0x%08X $$(($(APP_BASE)$(APP_SIZE)))) \ -offset -$(APP_BASE) \ -o dist/app_ota.bin -binary注意Makefile里对十六进制加减法的处理$(shell ...)调用的是Shell的算术能力不同系统对前导零的处理略有差异。我建议把地址数值存成十进制或统一格式的十六进制字符串避免在不同编译器环境里踩到预期之外的坑。7. 最后一个小建议把这些工具内化成习惯工具本身不难难的是什么时候想起来用它。我个人的习惯是每次固件构建脚本里需要做格式转换、地址操作、校验计算时第一反应就是用srec_cat而不是写一个临时脚本去处理。它用一条命令解决的事情用Python或者C写往往要几十行而且边界处理很容易出错。另一个习惯是把常用的srec_cat命令以Makefile target或者Shell函数的形式固化下来。比如上面的ota_package目标每次构建只要执行make ota_package就能得到带校验的OTA固件不用每次重新回忆参数。踩过几次坑之后你会发现srec_cat最需要记住的其实只有四点地址偏移注意正负、裁剪区间记住左闭右开、CRC校验字节序必须对齐、合并文件防止地址重叠。把这些刻进脑子里这套工具基本上不会再给你添麻烦。