先说明一下这次我不打算把Srecord当成本说明书来讲。因为真正上手用过的人都知道光看man srec_cat那一堆参数说明基本上一头雾水。我自己第一次接触这个工具是为了把编译出来的bin文件转成Intel HEX格式再烧进一块老旧的Flash芯片里结果被一堆地址偏移和校验和折腾得够呛。后来用熟了才发现Srecord在嵌入式文件处理这个领域几乎是绕不开的瑞士军刀——格式转换、固件合并、地址填充、C数组导出它一套命令就能搞定而且跨平台、开源免费比很多图形化工具靠谱得多。这篇内容适合所有做嵌入式开发、固件开发、单片机调试的工程师尤其是刚入行、还在用各种在线网页工具倒腾hex和bin的兄弟们看完这篇文章你可以把Srecord真正变成自己工具箱里的常驻成员。1. 为什么要用Srecord嵌入式文件处理的痛点1.1 文件格式转换是嵌软工程师的日常做过嵌入式开发的人应该都有这种感觉写代码只是工作量的三分之一剩下的时间全在跟各种文件格式打交道。编译器输出的可能是axf、elf链接脚本生成的可能是bin烧录工具可能要的是hex老旧的烧录器可能只认s19或者s28。更麻烦的是Bootloader和App往往要分开烧录有时候还需要在中间填充一段空白区域让地址对齐。这些需求堆在一起你会发现手动处理文件简直是噩梦。我之前有一段经历特别有代表性。当时维护一个基于STM32F103的产品现场升级固件用的是自定义Bootloader方案。Bootloader占前面16KBApp从0x08004000开始中间不允许有任何偏移Flash的空余区域必须全部填充为0xFF。编译工具链直接生成的bin文件是从0x08000000开始的完整镜像但实际要烧录的App区域却是从0x08004000开始。没接触过的人可能觉得这不是很简单么把前面16KB裁掉不就完了但裁掉之后地址信息就丢了烧录工具怎么知道这段数据要放到哪个地址后来就是在这个场景下我用Srecord彻底解决了问题一行命令就把裁剪、地址重映射、填充校验全部做完干净利落。1.2 Srecord能做什么一个工具搞定多种格式Srecord不是一个单一程序而是一套工具集其中最常用的是srec_cat、srec_info、srec_cmp这三个命令。srec_cat的核心能力是处理SREC格式的数据流它可以把Intel HEX、Motorola S-records19/s28/s37、二进制文件、Verilog、C语言数组等多种格式读进来经过裁剪、填充、偏移、拼接、生成校验等操作后再输出为任意支持的格式。srec_info用于查看文件的基本信息包括数据起始地址、结束地址、数据长度、校验类型等。srec_cmp则用于比较两个文件的内容是否一致在验证烧录文件正确性时非常好用。这个工具解决的核心问题是格式转换过程中的地址信息丢失。拿最常见的bin转hex来说bin文件只有裸数据没有任何地址信息。Srecord允许你在转换时显式指定基地址这样输出的hex文件就带上了完整的地址信息烧录器才知道这段数据该放到Flash的哪个位置。反过来hex转bin时Srecord可以自动处理地址段、裁剪填充、处理间隙不至于转出来的bin文件中间多出一长串无意义的0xFF数据。2. 快速上手Srecord的安装与初体验2.1 三种安装方式实测Srecord的安装在不同的平台上差别不大我实测下来基本上是零门槛。在Ubuntu和Debian系的Linux发行版上直接sudo apt install srecord装完之后验证一下srec_cat -VERSION在macOS上如果你用的是Homebrewbrew install srecord在Windows上稍微麻烦一点官方其实没有提供原生的Windows安装包。我常用的办法是用MSYS2或者WSL在MSYS2的终端里执行pacman -S mingw-w64-x86_64-srecord如果你不想装MSYS2也可以直接下载Windows二进制版本网上有热心网友编译好的但版本可能比较老。我个人还是推荐WSL或者MSYS2因为Srecord的命令行工具在类Unix环境下配合管道、批量脚本用起来才最顺手。源码编译安装的方式我也试过适合那些需要在离线环境或者特殊架构上使用的场景。源码包可以从SourceForge上下载编译过程基本是老三样./configure make sudo make install唯一的注意事项是Srecord依赖libstdc和一些基础库如果你的系统是精简版可能要先装一下build-essential之类的编译工具链。编译过程大概两三分钟比很多大型项目快多了。2.2 第一个命令用srec_info看清文件的真实面目装好工具之后我建议你先别急着做转换先用srec_info去“解剖”一个现有文件。这一步非常重要因为很多人在格式转换时出问题根本原因是没搞清楚源文件里到底有什么。假设你手头有一个固件文件先用下面的命令看它的底细srec_info firmware.hex输出大致是这样的Format: Intel Hexadecimal Execution start address: 0x08000000 Data: 0x08000000 - 0x08007FFF Word Count: 32768这几行信息极其关键它告诉你这个hex文件是什么格式Intel HEX执行起始地址在哪里如果有记录的话数据覆盖的地址范围是多少总共有多少字节。很多时候你发现转换出来的文件不对回头查一下这里的地址范围问题立刻就清楚了。srec_info还支持一次查看多个文件srec_info boot.hex app.hex这可以用来快速确认两个固件文件的地址区间是否重叠避免合并时互相覆盖。2.3 理解SREC格式的核心地址、数据、校验要真正用好Srecord理解它内部处理的数据模型比记命令重要得多。Srecord处理的核心是一种带地址的数据记录每一条记录由类型、长度、地址、数据、校验和组成这就是Motorola S-record格式的基本结构。常见的记录类型有S0文件头记录一般是文件名或者注释信息S116位地址的数据记录用于地址空间不超过64KB的场景S224位地址的数据记录适用于16MB以内的地址空间S332位地址的数据记录适用于更大的地址空间S5数据记录计数用于统计前面有多少条数据记录S7/S8/S9结束记录分别对应32位、24位、16位起始地址Intel HEX格式的底层逻辑也是一样的只是行格式和校验算法不同。Srecord内部把这几种格式统一抽象成“地址数据流”后续的所有操作都是基于这个抽象模型来做的。这就是为什么Srecord可以非常自然地在不同格式之间互相转换因为它根本不关心源文件具体是哪一种只关心数据本身的地址和内容。理解了这个模型后你就能理解为什么hex转bin需要指定地址范围因为bin文件没有地址信息Srecord只能把某一整段连续地址空间的数据导出成纯数据流中间如果有空隙要么填充指定的字节要么直接跳过不输出。3. 核心实操格式转换与文件处理的完整流程3.1 bin转hex让裸数据变成可烧录格式把bin文件转成Intel HEX格式嵌入式开发里最常见的操作之一。编译器生成的裸代码或者直接从Flash里读出来的备份都是没有地址信息的bin文件。要烧录这类文件必须给它加上地址信息。假设你的STM32工程编译输出了一个app.bin这个文件的基地址是0x08004000要转成app.hex命令如下srec_cat app.bin -binary -offset 0x08004000 -o app.hex -intel这条命令里有几个关键参数拆开来看app.bin输入文件-binary告诉Srecord这个文件是纯二进制格式-offset 0x08004000给这段二进制数据加上地址偏移也就是声明数据的起始地址-o app.hex指定输出文件-intel输出格式为Intel HEX执行完之后再用srec_info app.hex确认一下如果显示的数据地址范围是0x08004000到对应结束地址说明转换正确。实际项目中bin文件的基地址往往跟链接脚本里的FLASH_ORIGIN有关。比如STM32的默认链接脚本中App区域的起始地址是0x08004000那么这里填的就是0x08004000。如果你用的芯片是GD32、APM32这些国产替代型号只要内核是Cortex-M系列地址规则基本一致直接套用即可。3.2 hex转bin反向处理也有门道hex转bin的需求同样常见。比如你要在Linux主机上把hex固件合并到某个rootfs镜像里或者要用Python脚本分析固件内容都需要先把hex转成bin。命令格式是srec_cat app.hex -intel -o app.bin -binary看起来很简单但这里有一个隐藏的坑hex文件中的数据可能不是连续的。比如Bootloader的hex文件只包含了实际用到的代码区域而代码区域和后面的数据区域之间可能有空洞。直接把hex转成binSrecord会把空洞用0xFF填充掉得到的bin文件会非常大。比如一个hex文件的数据范围是0x08000000到0x0803FFFF但实际只用了前64KB后面都是空洞。转出来的bin文件大小就是256KB其中192KB是填充的0xFF。这种情况下如果烧录工具或者后续处理逻辑不关心这些填充数据倒也没问题。但如果bin文件是要加密签名后再传输多出来的192KB就会浪费带宽和时间。处理方法是先裁剪再转换srec_cat app.hex -intel -crop 0x08000000 0x08010000 -o app.bin -binary-crop参数把数据范围限制在0x08000000到0x08010000之间只输出这个范围内的数据其余全部丢弃。这样得到的bin文件就是干净的64KB。3.3 固件合并Bootloader与App空间的拼接合并Bootloader和App是Srecord最让我省心的场景之一以前没接触这个工具时我得先用Python脚本读hex文件按照地址分别提取数据再拼接输出一个新的hex代码写起来又臭又长。用Srecord只需要一条命令srec_cat boot.hex -intel app.hex -intel -o merge.hex -intel这条命令把两个hex文件的数据流合并在一起。Srecord会自动处理地址关系如果Bootloader的区域和App的区域地址不重叠合并后的文件就天然包含了两段数据烧录器会按照各自的地址写入Flash。这里有两个需要注意的地方。第一如果两个文件有地址重叠Srecord会默认报错退出防止数据互相覆盖。第二如果两个文件之间有地址空洞合并后的hex文件不会自动填充空洞数据段之间的间隙是真实存在的烧录器通常会自己处理这些间隙要么跳过要么填充0xFF。如果希望在合并的同时把间隙也填充上可以加上生成数据块的操作srec_cat boot.hex -intel app.hex -intel -fill 0xFF -over app.hex -o merge.hex -intel这个命令里的-fill 0xFF -over app.hex的作用是在合并文件的数据范围内把没有实际数据覆盖的地址全部填充为0xFF。-over app.hex表示填充范围不超过app.hex的数据区间。这样合并出来的文件从Bootloader到App结束地址之间整段地址空间都是连续、可预测的。3.4 数据填充与裁剪让地址空间干净有序有时候烧录工具要求整个Flash区域都有数据哪怕代码没用到的地方也要填上固定字节多数情况下填0xFF。Srecord的-generate和-fill组合可以实现这类需求。比如我想生成一个从0x08000000到0x0800FFFF、全部填充0xFF的16KB文件srec_cat -generate 0x08000000 0x08010000 -constant 0xFF -o blank.hex -intel这里-generate表示生成一段数据后面跟的是地址范围-constant 0xFF表示这一段数据全部填充为同一个字节值0xFF。这个功能在制作空Flash镜像、测试烧录器时特别有用。另一种常见情况是给现有文件补充尾部数据。比如你的App实际大小是17KB但为了让App区域的起始地址对齐到某个页边界需要把有效数据填充到20KB。用-fill配合-over就能做到srec_cat app.hex -intel -fill 0xFF -over app.hex -o app_aligned.hex -intel这个命令的意思是在整个数据范围内将所有没有实际数据的地址填上0xFF直到数据的最大地址为止。如果结合-crop还可以限制填充后的数据范围。3.5 偏移与切割处理不同Flash布局在实际项目中不同芯片的Flash起始地址不一样同一个固件可能要烧录到不同型号的芯片上这时候就需要对地址进行偏移操作。比如你有一个从0x08000000开始的完整Flash镜像现在要把它烧录到另一颗Flash起始地址为0x08010000的芯片上可以用-offsetsrec_cat full.hex -intel -offset 0x00010000 -o full_new_addr.hex -intel注意-offset是给所有数据记录的地址加上一个偏移量。如果源数据地址范围是0x08000000到0x0800FFFF偏移0x00010000后地址范围变成0x08010000到0x0801FFFF。这里偏移量可以是负数比如srec_cat full.hex -intel -offset -0x00010000 -o full_back.hex -intel就可以把地址整体往低地址方向移动。切割也很常用。有时候你手里的hex包含了整个固件的内容但只需要其中某一段。比如从0x08008000到0x0800FFFF这段数据是要拿出来单独分析或加密的srec_cat full.hex -intel -crop 0x08008000 0x08010000 -o segment.hex -intel这里-crop后面的两个地址是闭区间包含起始地址不包含结束地址。这一点要特别注意容易搞错边界。我还遇到过一种特殊需求一个文件里包含多段不连续的数据我要把其中一段取出并偏移到另一个地址。组合使用-crop和-offset就可以srec_cat full.hex -intel -crop 0x08008000 0x08010000 -offset -0x00008000 -o relocated.hex -intel4. 进阶玩法生成C数组、Verilog等多样化输出4.1 把固件转成C语言数组在嵌入式开发中有时候需要把固件作为常量数据嵌入到另一个工程里。典型场景是OTA升级包制作或者在没有文件系统的MCU上做自升级把新固件放在外部Flash里先缓存再拷贝到内部Flash。这种情况下把固件转成C语言头文件是最直接的做法。Srecord支持直接把bin或hex文件输出为C数组格式srec_cat app.bin -binary -offset 0x08004000 -o app.c -c-array firmware_data生成的文件大致长这样const unsigned char firmware_data[] { 0x00, 0x01, 0x02, ... };如果你需要带长度的数组Srecord也支持自定义数组名并且可以通过处理器相关的参数调整输出格式比如通过-c-array生成的数据默认是unsigned char类型如果你想用uint8_t可以加一个简单的sed或者直接用-c-array的辅助选项。我实际用下来最常见的方式是把bin转成C数组后再把数组引用到Bootloader工程里配合自定义的Flash写入驱动就可以实现App的本地升级功能。这个方法在STM32、GD32、NXP的LPC系列上都验证过稳定可靠。4.2 校验和与CRC给固件加一把锁很多Bootloader在接收上位机下发的固件时会先校验整个固件数据的CRC或者校验和确认数据无误后才允许烧录。Srecord内置了CRC32和其他几种校验算法的生成功能可以很方便地把校验值追加到固件文件末尾或者生成一个单独的校验值文件。生成带CRC32校验的固件srec_cat app.hex -intel -crc32-b-e 0x08004000 -o app_with_crc.hex -intel这里的-crc32-b-e参数的含义是在整个输入数据的范围内计算CRC32然后把CRC值以特定格式写入到地址0x08004000处。要注意0x08004000这个地址必须在你文件的数据范围之外否则会覆盖掉实际代码。CRC算法和校验值的存放位置、大小端格式不同的Bootloader有不同的约定。Srecord提供的-crc32-b-e是最常见的Big Endian、32位CRC32。如果你用的是小端格式也可以找相关的参数去匹配Bootloader的要求。此外Srecord还支持多种别的校验算法比如-crc16、-sum等等。用之前先确认Bootloader那边用什么算法两边不一致才是最折腾的。我建议在做校验功能前先写个小程序在PC上计算一组样本数据的校验值然后用Srecord计算同样的数据对比一下结果是否一致确认无误后再集成到产线流程里。4.3 输出为Verilog文件与VHDL文件这个功能虽然小众但在FPGA开发里有特殊价值。如果你要在FPGA里初始化一块ROM或者RAM可以用Srecord直接把固件转成Verilog的$readmemh格式文件srec_cat app.hex -intel -o app.hex.mem -vmem生成的.mem文件可以直接被Verilog的$readmemh读取省去了手动转换格式的麻烦。这个功能在我之前做软核处理器项目时派上过大用场把MCU的固件直接初始化到FPGA内部的Block RAM里免去了外挂Flash的麻烦。5. 常见问题与排查技巧实录5.1 地址越界与重叠用Srecord合并多个文件时最常遇到的报错就是地址重叠。比如Bootloader的hex文件到0x08003FFF结束App的hex文件从0x08004000开始按理说不会有重叠。但如果Bootloader的链接脚本配置了较大的栈区域或者特殊段地址范围可能会超出预期。解决方法是先用srec_info分别查看两个文件的地址范围确认没有重叠后再合并。如果确实有重叠检查链接脚本调整某个区域的起始地址。Srecord在地址重叠时会报错并停止操作这是它的保护机制不要慌仔细看提示信息就行。还有一种情况是数据超出芯片Flash容量。比如你的芯片Flash只有64KB地址范围是0x08000000到0x0800FFFF但合并后的文件数据到了0x08018000这说明某个文件的地址配置错了或者App区域起始地址没设置对。这时候用srec_info查看合并文件的数据范围对照芯片手册排查即可。5.2 校验和不匹配如果你在用Bootloader升级时总是报固件校验失败但明明用烧录器烧录后程序能跑问题大概率出在Bootloader对固件的校验算法和生成文件时用的算法不一致。我之前遇到一个典型的例子Bootloader用的是自定义的累加和校验从固件起始地址开始把每个字节累加取低16位作为校验值存在固件末尾两个字节。但我在生成固件时用的是Srecord的CRC32两边对不上升级永远失败。后来我在Bootloader代码里加了调试打印把期望值和实际值都打出来才发现是算法不匹配。排查思路是先在PC端用Python脚本复现Bootloader的算法对原始bin文件计算校验值确认算法理解无误然后用Srecord生成固件最后对比两者结果。只要算法一致Srecord算出来的值和Bootloader算出来的值一定相同。5.3 二进制文件处理时的长度问题bin转hex的过程中如果bin文件的大小不是偶数、或者地址没有对齐到烧录器要求的边界比如按页写入的Flash要求数据长度必须是页大小的整数倍烧录时可能会报长度错误。解决方案是在转换前把bin文件填充到合适的长度srec_cat app.bin -binary -offset 0x08004000 -fill 0xFF -over app.bin -o app_padded.hex -intel这条命令会先读取bin文件然后在数据的起始到结束范围内把空隙填充为0xFF。配合-crop可以裁剪到指定长度srec_cat app.bin -binary -offset 0x08004000 -fill 0xFF -over app.bin -crop 0x08004000 0x08008000 -o app_padded.hex -intel这样最后生成的固件长度就是0x4000字节即16KB满足常见的烧录对齐要求。5.4 其他常见坑位第一个坑是路径和文件名有空格。在Windows的MSYS2环境中如果文件路径包含空格直接用srec命令会解析出错。需要给文件名加引号比如srec_cat my app.bin -binary -offset 0x08004000 -o app.hex -intel第二个坑是-offset的符号。正数和负数代表的移动方向不同很多人在做反向偏移时容易搞混。-offset 0x1000是把地址往大地址方向移动-offset -0x1000是往小地址方向移动。只要记住“偏移量是加到所有数据地址上”的定义就不会错。第三个坑是输出文件的格式参数。-intel、-motorola、-binary这些格式符号的大小写不能错而且必须跟在输出文件名后面。写错格式参数不会报错但会生成一个内容完全不正确的文件。我建议每次转换后用srec_info检查一遍输出文件花不了几秒钟能避免烧录环节的大麻烦。第四个坑是当处理大文件时命令行不是万能的。一个几十MB的hex文件直接用srec命令行处理可能会比较慢但Srecord本身是流式处理的速度通常能接受。如果遇到大文件处理效率问题可以试试先裁剪出有效区域再处理。写在最后的一点经验我个人的习惯是在产线或者项目正式发布之前先用Srecord写一个小的批处理脚本把固件生成、格式转换、校验值计算、文件对比这些环节全部自动化。这样做的好处是每次编译完只需要跑一下脚本就能得到所有交付文件不会因为手动操作漏掉某个步骤导致格式错误。Srecord的命令行本质让它在自动化流程中如鱼得水无论是配合Makefile还是在CI/CD流水线里调用都很容易集成。实际使用中还有一个很实用的小技巧把Srecord的转换结果用srec_cmp和源文件做一次对比确认整个流程没有导致数据丢失或偏移错误。这个习惯让我避过好几次格式转换过程中地址偏移量填错的问题。尤其是当你把命令放进脚本之后如果某天不小心改了一个参数对比环节能第一时间发现问题不至于等到烧录阶段才暴露。
Srecord实战指南：嵌入式固件格式转换与合并处理技巧
先说明一下这次我不打算把Srecord当成本说明书来讲。因为真正上手用过的人都知道光看man srec_cat那一堆参数说明基本上一头雾水。我自己第一次接触这个工具是为了把编译出来的bin文件转成Intel HEX格式再烧进一块老旧的Flash芯片里结果被一堆地址偏移和校验和折腾得够呛。后来用熟了才发现Srecord在嵌入式文件处理这个领域几乎是绕不开的瑞士军刀——格式转换、固件合并、地址填充、C数组导出它一套命令就能搞定而且跨平台、开源免费比很多图形化工具靠谱得多。这篇内容适合所有做嵌入式开发、固件开发、单片机调试的工程师尤其是刚入行、还在用各种在线网页工具倒腾hex和bin的兄弟们看完这篇文章你可以把Srecord真正变成自己工具箱里的常驻成员。1. 为什么要用Srecord嵌入式文件处理的痛点1.1 文件格式转换是嵌软工程师的日常做过嵌入式开发的人应该都有这种感觉写代码只是工作量的三分之一剩下的时间全在跟各种文件格式打交道。编译器输出的可能是axf、elf链接脚本生成的可能是bin烧录工具可能要的是hex老旧的烧录器可能只认s19或者s28。更麻烦的是Bootloader和App往往要分开烧录有时候还需要在中间填充一段空白区域让地址对齐。这些需求堆在一起你会发现手动处理文件简直是噩梦。我之前有一段经历特别有代表性。当时维护一个基于STM32F103的产品现场升级固件用的是自定义Bootloader方案。Bootloader占前面16KBApp从0x08004000开始中间不允许有任何偏移Flash的空余区域必须全部填充为0xFF。编译工具链直接生成的bin文件是从0x08000000开始的完整镜像但实际要烧录的App区域却是从0x08004000开始。没接触过的人可能觉得这不是很简单么把前面16KB裁掉不就完了但裁掉之后地址信息就丢了烧录工具怎么知道这段数据要放到哪个地址后来就是在这个场景下我用Srecord彻底解决了问题一行命令就把裁剪、地址重映射、填充校验全部做完干净利落。1.2 Srecord能做什么一个工具搞定多种格式Srecord不是一个单一程序而是一套工具集其中最常用的是srec_cat、srec_info、srec_cmp这三个命令。srec_cat的核心能力是处理SREC格式的数据流它可以把Intel HEX、Motorola S-records19/s28/s37、二进制文件、Verilog、C语言数组等多种格式读进来经过裁剪、填充、偏移、拼接、生成校验等操作后再输出为任意支持的格式。srec_info用于查看文件的基本信息包括数据起始地址、结束地址、数据长度、校验类型等。srec_cmp则用于比较两个文件的内容是否一致在验证烧录文件正确性时非常好用。这个工具解决的核心问题是格式转换过程中的地址信息丢失。拿最常见的bin转hex来说bin文件只有裸数据没有任何地址信息。Srecord允许你在转换时显式指定基地址这样输出的hex文件就带上了完整的地址信息烧录器才知道这段数据该放到Flash的哪个位置。反过来hex转bin时Srecord可以自动处理地址段、裁剪填充、处理间隙不至于转出来的bin文件中间多出一长串无意义的0xFF数据。2. 快速上手Srecord的安装与初体验2.1 三种安装方式实测Srecord的安装在不同的平台上差别不大我实测下来基本上是零门槛。在Ubuntu和Debian系的Linux发行版上直接sudo apt install srecord装完之后验证一下srec_cat -VERSION在macOS上如果你用的是Homebrewbrew install srecord在Windows上稍微麻烦一点官方其实没有提供原生的Windows安装包。我常用的办法是用MSYS2或者WSL在MSYS2的终端里执行pacman -S mingw-w64-x86_64-srecord如果你不想装MSYS2也可以直接下载Windows二进制版本网上有热心网友编译好的但版本可能比较老。我个人还是推荐WSL或者MSYS2因为Srecord的命令行工具在类Unix环境下配合管道、批量脚本用起来才最顺手。源码编译安装的方式我也试过适合那些需要在离线环境或者特殊架构上使用的场景。源码包可以从SourceForge上下载编译过程基本是老三样./configure make sudo make install唯一的注意事项是Srecord依赖libstdc和一些基础库如果你的系统是精简版可能要先装一下build-essential之类的编译工具链。编译过程大概两三分钟比很多大型项目快多了。2.2 第一个命令用srec_info看清文件的真实面目装好工具之后我建议你先别急着做转换先用srec_info去“解剖”一个现有文件。这一步非常重要因为很多人在格式转换时出问题根本原因是没搞清楚源文件里到底有什么。假设你手头有一个固件文件先用下面的命令看它的底细srec_info firmware.hex输出大致是这样的Format: Intel Hexadecimal Execution start address: 0x08000000 Data: 0x08000000 - 0x08007FFF Word Count: 32768这几行信息极其关键它告诉你这个hex文件是什么格式Intel HEX执行起始地址在哪里如果有记录的话数据覆盖的地址范围是多少总共有多少字节。很多时候你发现转换出来的文件不对回头查一下这里的地址范围问题立刻就清楚了。srec_info还支持一次查看多个文件srec_info boot.hex app.hex这可以用来快速确认两个固件文件的地址区间是否重叠避免合并时互相覆盖。2.3 理解SREC格式的核心地址、数据、校验要真正用好Srecord理解它内部处理的数据模型比记命令重要得多。Srecord处理的核心是一种带地址的数据记录每一条记录由类型、长度、地址、数据、校验和组成这就是Motorola S-record格式的基本结构。常见的记录类型有S0文件头记录一般是文件名或者注释信息S116位地址的数据记录用于地址空间不超过64KB的场景S224位地址的数据记录适用于16MB以内的地址空间S332位地址的数据记录适用于更大的地址空间S5数据记录计数用于统计前面有多少条数据记录S7/S8/S9结束记录分别对应32位、24位、16位起始地址Intel HEX格式的底层逻辑也是一样的只是行格式和校验算法不同。Srecord内部把这几种格式统一抽象成“地址数据流”后续的所有操作都是基于这个抽象模型来做的。这就是为什么Srecord可以非常自然地在不同格式之间互相转换因为它根本不关心源文件具体是哪一种只关心数据本身的地址和内容。理解了这个模型后你就能理解为什么hex转bin需要指定地址范围因为bin文件没有地址信息Srecord只能把某一整段连续地址空间的数据导出成纯数据流中间如果有空隙要么填充指定的字节要么直接跳过不输出。3. 核心实操格式转换与文件处理的完整流程3.1 bin转hex让裸数据变成可烧录格式把bin文件转成Intel HEX格式嵌入式开发里最常见的操作之一。编译器生成的裸代码或者直接从Flash里读出来的备份都是没有地址信息的bin文件。要烧录这类文件必须给它加上地址信息。假设你的STM32工程编译输出了一个app.bin这个文件的基地址是0x08004000要转成app.hex命令如下srec_cat app.bin -binary -offset 0x08004000 -o app.hex -intel这条命令里有几个关键参数拆开来看app.bin输入文件-binary告诉Srecord这个文件是纯二进制格式-offset 0x08004000给这段二进制数据加上地址偏移也就是声明数据的起始地址-o app.hex指定输出文件-intel输出格式为Intel HEX执行完之后再用srec_info app.hex确认一下如果显示的数据地址范围是0x08004000到对应结束地址说明转换正确。实际项目中bin文件的基地址往往跟链接脚本里的FLASH_ORIGIN有关。比如STM32的默认链接脚本中App区域的起始地址是0x08004000那么这里填的就是0x08004000。如果你用的芯片是GD32、APM32这些国产替代型号只要内核是Cortex-M系列地址规则基本一致直接套用即可。3.2 hex转bin反向处理也有门道hex转bin的需求同样常见。比如你要在Linux主机上把hex固件合并到某个rootfs镜像里或者要用Python脚本分析固件内容都需要先把hex转成bin。命令格式是srec_cat app.hex -intel -o app.bin -binary看起来很简单但这里有一个隐藏的坑hex文件中的数据可能不是连续的。比如Bootloader的hex文件只包含了实际用到的代码区域而代码区域和后面的数据区域之间可能有空洞。直接把hex转成binSrecord会把空洞用0xFF填充掉得到的bin文件会非常大。比如一个hex文件的数据范围是0x08000000到0x0803FFFF但实际只用了前64KB后面都是空洞。转出来的bin文件大小就是256KB其中192KB是填充的0xFF。这种情况下如果烧录工具或者后续处理逻辑不关心这些填充数据倒也没问题。但如果bin文件是要加密签名后再传输多出来的192KB就会浪费带宽和时间。处理方法是先裁剪再转换srec_cat app.hex -intel -crop 0x08000000 0x08010000 -o app.bin -binary-crop参数把数据范围限制在0x08000000到0x08010000之间只输出这个范围内的数据其余全部丢弃。这样得到的bin文件就是干净的64KB。3.3 固件合并Bootloader与App空间的拼接合并Bootloader和App是Srecord最让我省心的场景之一以前没接触这个工具时我得先用Python脚本读hex文件按照地址分别提取数据再拼接输出一个新的hex代码写起来又臭又长。用Srecord只需要一条命令srec_cat boot.hex -intel app.hex -intel -o merge.hex -intel这条命令把两个hex文件的数据流合并在一起。Srecord会自动处理地址关系如果Bootloader的区域和App的区域地址不重叠合并后的文件就天然包含了两段数据烧录器会按照各自的地址写入Flash。这里有两个需要注意的地方。第一如果两个文件有地址重叠Srecord会默认报错退出防止数据互相覆盖。第二如果两个文件之间有地址空洞合并后的hex文件不会自动填充空洞数据段之间的间隙是真实存在的烧录器通常会自己处理这些间隙要么跳过要么填充0xFF。如果希望在合并的同时把间隙也填充上可以加上生成数据块的操作srec_cat boot.hex -intel app.hex -intel -fill 0xFF -over app.hex -o merge.hex -intel这个命令里的-fill 0xFF -over app.hex的作用是在合并文件的数据范围内把没有实际数据覆盖的地址全部填充为0xFF。-over app.hex表示填充范围不超过app.hex的数据区间。这样合并出来的文件从Bootloader到App结束地址之间整段地址空间都是连续、可预测的。3.4 数据填充与裁剪让地址空间干净有序有时候烧录工具要求整个Flash区域都有数据哪怕代码没用到的地方也要填上固定字节多数情况下填0xFF。Srecord的-generate和-fill组合可以实现这类需求。比如我想生成一个从0x08000000到0x0800FFFF、全部填充0xFF的16KB文件srec_cat -generate 0x08000000 0x08010000 -constant 0xFF -o blank.hex -intel这里-generate表示生成一段数据后面跟的是地址范围-constant 0xFF表示这一段数据全部填充为同一个字节值0xFF。这个功能在制作空Flash镜像、测试烧录器时特别有用。另一种常见情况是给现有文件补充尾部数据。比如你的App实际大小是17KB但为了让App区域的起始地址对齐到某个页边界需要把有效数据填充到20KB。用-fill配合-over就能做到srec_cat app.hex -intel -fill 0xFF -over app.hex -o app_aligned.hex -intel这个命令的意思是在整个数据范围内将所有没有实际数据的地址填上0xFF直到数据的最大地址为止。如果结合-crop还可以限制填充后的数据范围。3.5 偏移与切割处理不同Flash布局在实际项目中不同芯片的Flash起始地址不一样同一个固件可能要烧录到不同型号的芯片上这时候就需要对地址进行偏移操作。比如你有一个从0x08000000开始的完整Flash镜像现在要把它烧录到另一颗Flash起始地址为0x08010000的芯片上可以用-offsetsrec_cat full.hex -intel -offset 0x00010000 -o full_new_addr.hex -intel注意-offset是给所有数据记录的地址加上一个偏移量。如果源数据地址范围是0x08000000到0x0800FFFF偏移0x00010000后地址范围变成0x08010000到0x0801FFFF。这里偏移量可以是负数比如srec_cat full.hex -intel -offset -0x00010000 -o full_back.hex -intel就可以把地址整体往低地址方向移动。切割也很常用。有时候你手里的hex包含了整个固件的内容但只需要其中某一段。比如从0x08008000到0x0800FFFF这段数据是要拿出来单独分析或加密的srec_cat full.hex -intel -crop 0x08008000 0x08010000 -o segment.hex -intel这里-crop后面的两个地址是闭区间包含起始地址不包含结束地址。这一点要特别注意容易搞错边界。我还遇到过一种特殊需求一个文件里包含多段不连续的数据我要把其中一段取出并偏移到另一个地址。组合使用-crop和-offset就可以srec_cat full.hex -intel -crop 0x08008000 0x08010000 -offset -0x00008000 -o relocated.hex -intel4. 进阶玩法生成C数组、Verilog等多样化输出4.1 把固件转成C语言数组在嵌入式开发中有时候需要把固件作为常量数据嵌入到另一个工程里。典型场景是OTA升级包制作或者在没有文件系统的MCU上做自升级把新固件放在外部Flash里先缓存再拷贝到内部Flash。这种情况下把固件转成C语言头文件是最直接的做法。Srecord支持直接把bin或hex文件输出为C数组格式srec_cat app.bin -binary -offset 0x08004000 -o app.c -c-array firmware_data生成的文件大致长这样const unsigned char firmware_data[] { 0x00, 0x01, 0x02, ... };如果你需要带长度的数组Srecord也支持自定义数组名并且可以通过处理器相关的参数调整输出格式比如通过-c-array生成的数据默认是unsigned char类型如果你想用uint8_t可以加一个简单的sed或者直接用-c-array的辅助选项。我实际用下来最常见的方式是把bin转成C数组后再把数组引用到Bootloader工程里配合自定义的Flash写入驱动就可以实现App的本地升级功能。这个方法在STM32、GD32、NXP的LPC系列上都验证过稳定可靠。4.2 校验和与CRC给固件加一把锁很多Bootloader在接收上位机下发的固件时会先校验整个固件数据的CRC或者校验和确认数据无误后才允许烧录。Srecord内置了CRC32和其他几种校验算法的生成功能可以很方便地把校验值追加到固件文件末尾或者生成一个单独的校验值文件。生成带CRC32校验的固件srec_cat app.hex -intel -crc32-b-e 0x08004000 -o app_with_crc.hex -intel这里的-crc32-b-e参数的含义是在整个输入数据的范围内计算CRC32然后把CRC值以特定格式写入到地址0x08004000处。要注意0x08004000这个地址必须在你文件的数据范围之外否则会覆盖掉实际代码。CRC算法和校验值的存放位置、大小端格式不同的Bootloader有不同的约定。Srecord提供的-crc32-b-e是最常见的Big Endian、32位CRC32。如果你用的是小端格式也可以找相关的参数去匹配Bootloader的要求。此外Srecord还支持多种别的校验算法比如-crc16、-sum等等。用之前先确认Bootloader那边用什么算法两边不一致才是最折腾的。我建议在做校验功能前先写个小程序在PC上计算一组样本数据的校验值然后用Srecord计算同样的数据对比一下结果是否一致确认无误后再集成到产线流程里。4.3 输出为Verilog文件与VHDL文件这个功能虽然小众但在FPGA开发里有特殊价值。如果你要在FPGA里初始化一块ROM或者RAM可以用Srecord直接把固件转成Verilog的$readmemh格式文件srec_cat app.hex -intel -o app.hex.mem -vmem生成的.mem文件可以直接被Verilog的$readmemh读取省去了手动转换格式的麻烦。这个功能在我之前做软核处理器项目时派上过大用场把MCU的固件直接初始化到FPGA内部的Block RAM里免去了外挂Flash的麻烦。5. 常见问题与排查技巧实录5.1 地址越界与重叠用Srecord合并多个文件时最常遇到的报错就是地址重叠。比如Bootloader的hex文件到0x08003FFF结束App的hex文件从0x08004000开始按理说不会有重叠。但如果Bootloader的链接脚本配置了较大的栈区域或者特殊段地址范围可能会超出预期。解决方法是先用srec_info分别查看两个文件的地址范围确认没有重叠后再合并。如果确实有重叠检查链接脚本调整某个区域的起始地址。Srecord在地址重叠时会报错并停止操作这是它的保护机制不要慌仔细看提示信息就行。还有一种情况是数据超出芯片Flash容量。比如你的芯片Flash只有64KB地址范围是0x08000000到0x0800FFFF但合并后的文件数据到了0x08018000这说明某个文件的地址配置错了或者App区域起始地址没设置对。这时候用srec_info查看合并文件的数据范围对照芯片手册排查即可。5.2 校验和不匹配如果你在用Bootloader升级时总是报固件校验失败但明明用烧录器烧录后程序能跑问题大概率出在Bootloader对固件的校验算法和生成文件时用的算法不一致。我之前遇到一个典型的例子Bootloader用的是自定义的累加和校验从固件起始地址开始把每个字节累加取低16位作为校验值存在固件末尾两个字节。但我在生成固件时用的是Srecord的CRC32两边对不上升级永远失败。后来我在Bootloader代码里加了调试打印把期望值和实际值都打出来才发现是算法不匹配。排查思路是先在PC端用Python脚本复现Bootloader的算法对原始bin文件计算校验值确认算法理解无误然后用Srecord生成固件最后对比两者结果。只要算法一致Srecord算出来的值和Bootloader算出来的值一定相同。5.3 二进制文件处理时的长度问题bin转hex的过程中如果bin文件的大小不是偶数、或者地址没有对齐到烧录器要求的边界比如按页写入的Flash要求数据长度必须是页大小的整数倍烧录时可能会报长度错误。解决方案是在转换前把bin文件填充到合适的长度srec_cat app.bin -binary -offset 0x08004000 -fill 0xFF -over app.bin -o app_padded.hex -intel这条命令会先读取bin文件然后在数据的起始到结束范围内把空隙填充为0xFF。配合-crop可以裁剪到指定长度srec_cat app.bin -binary -offset 0x08004000 -fill 0xFF -over app.bin -crop 0x08004000 0x08008000 -o app_padded.hex -intel这样最后生成的固件长度就是0x4000字节即16KB满足常见的烧录对齐要求。5.4 其他常见坑位第一个坑是路径和文件名有空格。在Windows的MSYS2环境中如果文件路径包含空格直接用srec命令会解析出错。需要给文件名加引号比如srec_cat my app.bin -binary -offset 0x08004000 -o app.hex -intel第二个坑是-offset的符号。正数和负数代表的移动方向不同很多人在做反向偏移时容易搞混。-offset 0x1000是把地址往大地址方向移动-offset -0x1000是往小地址方向移动。只要记住“偏移量是加到所有数据地址上”的定义就不会错。第三个坑是输出文件的格式参数。-intel、-motorola、-binary这些格式符号的大小写不能错而且必须跟在输出文件名后面。写错格式参数不会报错但会生成一个内容完全不正确的文件。我建议每次转换后用srec_info检查一遍输出文件花不了几秒钟能避免烧录环节的大麻烦。第四个坑是当处理大文件时命令行不是万能的。一个几十MB的hex文件直接用srec命令行处理可能会比较慢但Srecord本身是流式处理的速度通常能接受。如果遇到大文件处理效率问题可以试试先裁剪出有效区域再处理。写在最后的一点经验我个人的习惯是在产线或者项目正式发布之前先用Srecord写一个小的批处理脚本把固件生成、格式转换、校验值计算、文件对比这些环节全部自动化。这样做的好处是每次编译完只需要跑一下脚本就能得到所有交付文件不会因为手动操作漏掉某个步骤导致格式错误。Srecord的命令行本质让它在自动化流程中如鱼得水无论是配合Makefile还是在CI/CD流水线里调用都很容易集成。实际使用中还有一个很实用的小技巧把Srecord的转换结果用srec_cmp和源文件做一次对比确认整个流程没有导致数据丢失或偏移错误。这个习惯让我避过好几次格式转换过程中地址偏移量填错的问题。尤其是当你把命令放进脚本之后如果某天不小心改了一个参数对比环节能第一时间发现问题不至于等到烧录阶段才暴露。
