1. 项目概述为什么需要合并HEX文件在嵌入式开发尤其是基于AVR、STM32、GD32这类微控制器的项目中我们经常会遇到一个非常实际的需求将两个独立的HEX文件合并成一个。最常见的场景就是将Bootloader引导加载程序和应用程序Application的HEX文件合二为一。你可能会有疑问我分别烧录Bootloader和App不就行了吗为什么非要合并这里面的门道恰恰是量产和固件管理效率的关键。想象一下你开发了一个智能硬件产品它支持通过USB或者蓝牙进行固件升级OTA。产品出厂时Flash存储器里需要预先写好两段代码一段是负责通信、校验和跳转的Bootloader通常固定在Flash的起始地址比如0x0000另一段是实现产品核心功能的应用程序紧随Bootloader之后比如从0x2000开始。在工厂生产线上如果让工人分两次烧录不仅效率低下还极易出错。更优雅的做法是我们在研发端就将这两个已经编译好的、地址不重叠的HEX文件合并成一个“完整版”的固件HEX。这样生产线上的烧录器只需要烧录这一个文件就能一次性将整个系统写入芯片大大简化了生产流程也保证了固件版本的一致性。另一个常见需求是制作“带升级功能的出厂固件包”。你希望用户拿到的第一个版本就包含了能自我升级的Bootloader。合并HEX文件就是生成这个“一体化固件”的标准操作。围绕这个需求网络上充斥着各种问题和搜索热词比如“cannot load flash programming algorithm!”、“flash download failed”、“no algorithm found for…”很多都源于合并或烧录过程中地址冲突、格式错误等底层问题。今天我就结合十多年的踩坑经验带你彻底搞懂HEX文件格式并手把手演示几种主流、可靠的合并方法。2. HEX文件格式深度解析在动手合并之前我们必须先理解我们在操作什么。HEX文件全称Intel HEX文件是一种用ASCII文本格式表示二进制机器码的标准。它并非二进制本身而是一种“带地址标签的搬运清单”。理解它的结构是避免后续各种“玄学”错误的基础。2.1 HEX文件记录结构剖析一个典型的HEX文件由一行行Record组成每行代表一段连续的数据、一个地址偏移或一个结束标志。每一行都遵循固定的格式:BBAAAATTHHHH...HHHHCC看起来像天书我们来拆解每一个字段:每行的起始标志符。BB 一个字节长度的十六进制数表示本行数据字节的长度。例如10表示后面有16个字节的数据。AAAA 两个字节长度的十六进制数表示本行数据的起始地址偏移量。这个地址是相对于“基地址”的偏移。基地址由之前的扩展地址记录类型04或线性地址记录类型02设定。TT 记录类型这是HEX文件的灵魂。常见的有00数据记录。这是最主要的部分承载着实际的程序代码或数据。01文件结束记录。标志HEX文件的结尾通常为:00000001FF。02扩展段地址记录。用于设置20位地址的高4位在8086等分段内存模型中常见。04扩展线性地址记录。这是我们现代32位MCU最常用的它用于设置32位地址的高16位。例如一行:020000040800F2表示将后续数据记录的基地址设置为0x0800 0000STM32 Flash的常见起始地址。那么后续一个:1000000048C09FE51CFF2FE1...的数据记录其实际物理地址就是0x0800 0000 0x0000 0x0800 0000。05 起始线性地址记录用于指示程序的入口地址如ARM Cortex-M的复位向量。HHHH...HHHH 实际的数据字节以十六进制ASCII码表示长度为2 * BB。CC 校验和。计算方法是从BB开始到最后一个数据字节HH的所有字节值求和取结果的二进制补码即用0x100减去和值的低字节。校验和用于验证该行数据在传输或存储过程中没有出错。注意校验和的计算是新手最容易忽略的坑。当你手动修改或合并HEX文件时如果忘记重新计算某行的校验和烧录工具很可能会报“校验和错误”而拒绝烧录或者更隐蔽地烧录后程序跑飞。2.2 Bootloader与App的HEX文件地址布局理解地址布局是成功合并的前提。合并的本质是将两段地址空间不重叠的代码拼接到一个统一的地址映射中。以一个典型的STM32F103 Bootloader项目为例Bootloader HEX 它通常从Flash的起始地址0x0800 0000开始。假设Bootloader代码编译后大小为8KB那么它占用的地址范围就是0x0800 0000~0x0800 1FFF。它的HEX文件里会包含一个:020000040800F2记录以及从0x0000开始的数据记录。应用程序 HEX 应用程序不能从0x0800 0000开始否则会覆盖Bootloader。我们需要在编译时通过修改链接脚本Linker Script将应用程序的起始地址设置为Bootloader之后的地址例如0x0800 2000。因此应用程序的HEX文件里会包含一个:020000040800F2记录基地址相同但它的数据记录起始地址偏移会是0x2000。这样两个HEX文件虽然基地址都是0x0800 0000但它们的数据记录地址偏移是错开的。合并的任务就是把这两个文件中的所有数据记录类型00提取出来按照其正确的物理地址排序并重新组织成一个新的、包含所有数据记录的HEX文件最后加上统一的结束记录。如果地址发生重叠比如App的某段代码错误地链接到了0x0800 1000而这个地址已经被Bootloader占用合并后的固件在运行时必然会发生不可预知的行为这是最严重的错误之一。3. 合并方案选型与工具实战明白了原理我们来看看具体怎么做。有多种工具和方法可以实现HEX合并我将从最简单到最强大逐一介绍并分析其适用场景和潜在陷阱。3.1 方案一使用srec_cat工具跨平台首选srec_cat是srecord工具集里的瑞士军刀功能极其强大是处理各种固件格式HEX, BIN, S-record等的行业标准工具之一。它跨平台Windows, Linux, macOS可以通过命令行进行精细控制。1. 安装srecord工具Ubuntu/Debian:sudo apt-get install srecordWindows: 可以从SourceForge等网站下载预编译的二进制包或者通过MSYS2、Cygwin环境安装。macOS:brew install srecord2. 基础合并命令假设你的Bootloader文件是bootloader.hex应用程序文件是app.hex想要输出合并后的firmware.hex。srec_cat bootloader.hex -Intel app.hex -Intel -o firmware.hex -Intel这个命令非常简单按顺序读取两个Intel HEX格式的文件然后输出为一个Intel HEX格式的文件。srec_cat会自动处理地址问题如果地址有重叠默认情况下后面的输入文件会覆盖前面的。3. 高级功能与避坑指南地址填充Gap Filling 如果Bootloader和App的地址不是紧密相连中间有空白比如Bootloader实际只用了6KB但我们为它保留了8KB的空间App从8KB后开始直接合并会导致中间有一段地址没有数据。有些烧录器或校验工具会认为这是“空洞”而报错。此时可以用-fill参数填充空白区域通常用0xFFFlash擦除后的状态填充。srec_cat bootloader.hex -Intel -fill 0xFF 0x08000000 0x08002000 app.hex -Intel -o firmware.hex -Intel这个命令在0x08000000到0x08002000的范围内用0xFF填充所有未被bootloader.hex覆盖的地址然后再合并app.hex。生成二进制文件BIN 有时烧录工具或OTA升级包需要纯二进制BIN格式。srec_cat可以轻松转换。srec_cat bootloader.hex -Intel app.hex -Intel -o firmware.bin -Binary但要注意BIN文件没有地址信息。你必须确保从起始地址到结束地址的所有字节都有定义通过填充否则生成的BIN文件会“缺失”中间段长度不对。处理地址重叠冲突 这是最需要警惕的情况。如果两个文件地址有重叠srec_cat默认行为是“后者覆盖前者”这可能不是你想要的。你应该首先检查链接脚本确保编译时地址没有冲突。可以使用srec_info命令查看HEX文件的地址范围srec_info bootloader.hex srec_info app.hex实操心得在自动化构建脚本如Makefile或CI/CD流水线中我强烈推荐使用srec_cat。它的命令行接口稳定参数明确易于集成。务必在脚本中加入地址范围检查的步骤防患于未然。3.2 方案二使用J-Flash工具GUI界面STM32友好如果你主要使用ST的STM32系列并且使用J-Link作为调试器那么SEGGER公司提供的J-Flash软件是一个带有图形界面、非常方便的选择。它不仅能烧录也能合并和修改固件。操作步骤打开J-Flash选择创建新工程并匹配你的芯片型号。点击File-Open data file...首先打开bootloader.hex。数据会被加载到内存缓冲区并在地图视图中显示。再次点击File-Merge data file...选择app.hex。此时会弹出合并选项对话框。关键选项是“Address range handling”Auto 自动处理通常就是覆盖。Preserve old data 保留已加载的数据即bootloader忽略新文件中重叠部分。这是我们通常需要的选项Overwrite with new data 用新数据覆盖。选择Preserve old data点击OK。你会发现App的数据被“叠加”到了Bootloader之后正确的地址上。最后点击File-Save data file as...保存合并后的HEX文件。优点 可视化可以直观地看到地址映射和冲突适合不熟悉命令行的开发者或进行一次性操作。缺点 难以集成到自动化脚本中且是商业软件虽然通常随J-Link提供。3.3 方案三使用Python脚本高度自定义对于有特殊需求或者想将合并逻辑深度集成到内部工具链的情况自己写一个Python脚本是最灵活的方式。Python的intelhex库让这一切变得非常简单。1. 安装intelhex库pip install intelhex2. 编写合并脚本merge_hex.py#!/usr/bin/env python3 import sys from intelhex import IntelHex def main(): if len(sys.argv) 4: print(Usage: python merge_hex.py bootloader.hex app.hex output.hex) sys.exit(1) bootloader_file sys.argv[1] app_file sys.argv[2] output_file sys.argv[3] # 创建IntelHex对象并加载文件 ih_boot IntelHex() ih_app IntelHex() ih_boot.loadhex(bootloader_file) ih_app.loadhex(app_file) # 关键步骤将App的数据合并到Bootloader中。 # overlap 参数决定重叠时的行为 # error - 抛出异常 (推荐用于严格检查) # ignore - 保留旧数据即bootloader # replace - 用新数据替换旧数据 try: ih_boot.merge(ih_app, overlaperror) print(Merge successful. No address overlap detected.) except Exception as e: print(fError during merge: {e}) print(Address overlap detected! Please check your linker scripts.) sys.exit(1) # 写入合并后的HEX文件 ih_boot.write_hex_file(output_file) print(fMerged HEX file saved as: {output_file}) if __name__ __main__: main()3. 使用脚本python merge_hex.py bootloader.hex app.hex firmware.hex脚本的优势完全可控你可以定制任何逻辑比如在合并前自动进行CRC校验、填充特定模式、插入版本信息等。自动化集成可以无缝嵌入到任何基于Python的构建系统如SCons, Meson或CI/CD流程如GitLab CI, Jenkins中。严格的错误检查如上例设置overlaperror可以在合并时立即发现地址冲突而不是生成一个有隐患的固件。4. 合并前后的关键验证与调试合并生成firmware.hex并不意味着万事大吉。在将其烧录到芯片或交付给生产线之前必须进行严格的验证。4.1 验证合并结果查看地址范围 使用srec_info或objdump工具查看合并后文件的地址范围确认是否覆盖了从Bootloader起始到应用程序结束的全部区域且中间没有“空洞”除非你故意留空。srec_info firmware.hex校验和与CRC 虽然HEX文件每行有校验和但整个镜像的完整性通常需要计算CRC32或MD5。你可以用一个小脚本计算合并前后文件的哈希值确保数据没有在合并过程中损坏。一些高级的Bootloader协议也会要求应用程序镜像包含一个尾部的CRC校验值这个值需要在合并后重新计算并填入。向量表检查 对于ARM Cortex-M内核应用程序的起始地址即中断向量表必须正确。合并后应用程序的复位向量通常是第二字指向Reset_Handler的地址必须是它的实际物理地址。你可以用十六进制编辑器或arm-none-eabi-objdump工具查看合并后HEX文件中对应地址的数据进行验证。4.2 烧录与调试避坑指南很多网络热词反映的问题其实就发生在烧录合并后的固件这一步。“cannot load flash programming algorithm!” / “flash download failed”原因1地址超出范围。你为烧录工具如Keil MDK, IAR, STM32CubeProgrammer指定的下载算法Algorithm可能没有覆盖你合并后固件的整个地址范围。特别是如果你将App链接到了非常大的地址例如外部Flash需要确保算法文件.FLM或 .elf支持该区域。解决方法 在IDE的下载配置中检查并编辑Flash算法确保其Start和Size包含了你的固件所有部分。或者使用命令行工具如OpenOCD, pyOCD直接指定整个镜像文件。“no algorithm found for: 00008000h - 00008753h erase skipped!”原因 这个错误明确指出了工具找不到对应地址段的擦除/编程算法。和上一个问题类似是算法配置不匹配。解决方法 同样需要修正Flash算法配置。有时合并后的文件包含了一些位于系统内存、选项字节Option Bytes区域的数据这些区域需要特殊的编程方式并非所有算法都支持。检查你的HEX文件是否不小心包含了这些区域的数据。程序跳转失败Bootloader跳转后App不执行原因 这是合并后最经典的运行时问题。可能原因有App的向量表地址未重映射 Bootloader跳转前需要将MCU的中断向量表偏移寄存器如Cortex-M的VTOR设置为App向量表的起始地址。如果忘记设置中断发生时CPU还是会去Bootloader的区域找向量导致崩溃。时钟或外设未重新初始化 Bootloader可能为了通信修改了系统时钟比如提升了HCLK频率。跳转到App时如果App的初始化代码基于默认时钟配置可能会导致时序错误。稳妥的做法是在跳转前将关键外设特别是时钟、中断控制器恢复到复位状态或者确保App的初始化代码能覆盖所有Bootloader做过的配置。堆栈指针SP未正确加载 App向量表的第一个字是初始堆栈指针。Bootloader的跳转指令必须能正确加载这个值。调试方法 使用调试器单步跟踪Bootloader的跳转指令通常是汇编语句BX或函数指针调用检查跳转前后的寄存器值尤其是PC, SP, VTOR。同时检查App起始地址处的数据确认前两个字SP和Reset_Handler地址是否正确。5. 进阶话题与生产实践5.1 制作带CRC校验的完整固件包在量产中为了确保固件在传输和烧录过程中的完整性我们通常会在合并后的固件末尾附加一个CRC32校验值。Bootloader在升级时会先计算接收到的固件的CRC与附带的校验值比对一致后才执行烧录。操作流程合并Bootloader和App的HEX得到firmware.hex。将firmware.hex转换为纯二进制firmware.bin。使用工具如crc32命令行工具或Python的zlib库计算firmware.bin的CRC32值。将这个4字节的CRC值以小端序Little-Endian追加到firmware.bin的末尾。可选将追加了CRC的BIN文件再转换回HEX格式得到最终用于发布的firmware_with_crc.hex。这样你的发布包就是一个自包含、可校验的完整实体。5.2 自动化构建流水线集成在现代嵌入式开发中固件构建应该是一个一键完成、可重复的过程。我推荐将HEX合并作为构建脚本的最后一步。一个基于Makefile的简单示例# 假设你的工程编译后生成 bootloader.hex 和 app.hex ALL_HEX bootloader.hex app.hex # 最终目标 firmware.hex: $(ALL_HEX) echo Merging HEX files... srec_cat bootloader.hex -Intel app.hex -Intel -fill 0xFF 0x08000000 0x08010000 -o firmware.hex -Intel echo Generating BIN with CRC... # 步骤 HEX转BIN - 计算CRC - 追加CRC - (可选)BIN转回HEX objcopy -I ihex -O binary firmware.hex firmware.bin # ... 计算CRC并追加的命令 ... echo Firmware image ready. .PHONY: clean clean: rm -f firmware.hex firmware.bin在CI/CD服务器如GitLab Runner, Jenkins上每次代码提交或打标签时自动执行这个make命令就能生成可直接用于测试或生产的固件镜像保证了交付物的一致性。5.3 应对复杂内存布局对于一些高级芯片内存布局可能更复杂多块非连续Flash 芯片内部有多块独立的Flash存储区。将部分代码/数据链接到RAM中执行 为了追求极致性能。包含配置信息如Option Bytes 这些数据有特定的地址和格式。在这种情况下合并HEX文件不能简单地使用srec_cat file1.hex file2.hex。你需要为每一块需要编程的区域准备独立的HEX文件或独立的段然后使用srec_cat的地址映射功能将它们“拼凑”到同一个物理地址空间视图下或者直接生成多个独立的烧录文件供烧录器使用。处理这类问题的核心依然是精确理解链接脚本.ld文件和生成的HEX文件的地址分布。工具只是执行者你对内存布局的理解才是成功的关键。合并HEX文件这个看似简单的操作串联起了嵌入式开发中的编译、链接、地址空间管理和生产烧录等多个关键环节。掌握它不仅能让你轻松应对BootloaderApp的经典场景更能让你深入理解固件在芯片中的物理存在形式从而在遇到更复杂的存储管理、固件升级和量产问题时能够游刃有余地从底层原理找到解决方案。希望这篇详尽的拆解能帮你彻底扫清合并之路上的所有障碍。
1. 项目概述为什么需要合并HEX文件在嵌入式开发尤其是基于AVR、STM32、GD32这类微控制器的项目中我们经常会遇到一个非常实际的需求将两个独立的HEX文件合并成一个。最常见的场景就是将Bootloader引导加载程序和应用程序Application的HEX文件合二为一。你可能会有疑问我分别烧录Bootloader和App不就行了吗为什么非要合并这里面的门道恰恰是量产和固件管理效率的关键。想象一下你开发了一个智能硬件产品它支持通过USB或者蓝牙进行固件升级OTA。产品出厂时Flash存储器里需要预先写好两段代码一段是负责通信、校验和跳转的Bootloader通常固定在Flash的起始地址比如0x0000另一段是实现产品核心功能的应用程序紧随Bootloader之后比如从0x2000开始。在工厂生产线上如果让工人分两次烧录不仅效率低下还极易出错。更优雅的做法是我们在研发端就将这两个已经编译好的、地址不重叠的HEX文件合并成一个“完整版”的固件HEX。这样生产线上的烧录器只需要烧录这一个文件就能一次性将整个系统写入芯片大大简化了生产流程也保证了固件版本的一致性。另一个常见需求是制作“带升级功能的出厂固件包”。你希望用户拿到的第一个版本就包含了能自我升级的Bootloader。合并HEX文件就是生成这个“一体化固件”的标准操作。围绕这个需求网络上充斥着各种问题和搜索热词比如“cannot load flash programming algorithm!”、“flash download failed”、“no algorithm found for…”很多都源于合并或烧录过程中地址冲突、格式错误等底层问题。今天我就结合十多年的踩坑经验带你彻底搞懂HEX文件格式并手把手演示几种主流、可靠的合并方法。2. HEX文件格式深度解析在动手合并之前我们必须先理解我们在操作什么。HEX文件全称Intel HEX文件是一种用ASCII文本格式表示二进制机器码的标准。它并非二进制本身而是一种“带地址标签的搬运清单”。理解它的结构是避免后续各种“玄学”错误的基础。2.1 HEX文件记录结构剖析一个典型的HEX文件由一行行Record组成每行代表一段连续的数据、一个地址偏移或一个结束标志。每一行都遵循固定的格式:BBAAAATTHHHH...HHHHCC看起来像天书我们来拆解每一个字段:每行的起始标志符。BB 一个字节长度的十六进制数表示本行数据字节的长度。例如10表示后面有16个字节的数据。AAAA 两个字节长度的十六进制数表示本行数据的起始地址偏移量。这个地址是相对于“基地址”的偏移。基地址由之前的扩展地址记录类型04或线性地址记录类型02设定。TT 记录类型这是HEX文件的灵魂。常见的有00数据记录。这是最主要的部分承载着实际的程序代码或数据。01文件结束记录。标志HEX文件的结尾通常为:00000001FF。02扩展段地址记录。用于设置20位地址的高4位在8086等分段内存模型中常见。04扩展线性地址记录。这是我们现代32位MCU最常用的它用于设置32位地址的高16位。例如一行:020000040800F2表示将后续数据记录的基地址设置为0x0800 0000STM32 Flash的常见起始地址。那么后续一个:1000000048C09FE51CFF2FE1...的数据记录其实际物理地址就是0x0800 0000 0x0000 0x0800 0000。05 起始线性地址记录用于指示程序的入口地址如ARM Cortex-M的复位向量。HHHH...HHHH 实际的数据字节以十六进制ASCII码表示长度为2 * BB。CC 校验和。计算方法是从BB开始到最后一个数据字节HH的所有字节值求和取结果的二进制补码即用0x100减去和值的低字节。校验和用于验证该行数据在传输或存储过程中没有出错。注意校验和的计算是新手最容易忽略的坑。当你手动修改或合并HEX文件时如果忘记重新计算某行的校验和烧录工具很可能会报“校验和错误”而拒绝烧录或者更隐蔽地烧录后程序跑飞。2.2 Bootloader与App的HEX文件地址布局理解地址布局是成功合并的前提。合并的本质是将两段地址空间不重叠的代码拼接到一个统一的地址映射中。以一个典型的STM32F103 Bootloader项目为例Bootloader HEX 它通常从Flash的起始地址0x0800 0000开始。假设Bootloader代码编译后大小为8KB那么它占用的地址范围就是0x0800 0000~0x0800 1FFF。它的HEX文件里会包含一个:020000040800F2记录以及从0x0000开始的数据记录。应用程序 HEX 应用程序不能从0x0800 0000开始否则会覆盖Bootloader。我们需要在编译时通过修改链接脚本Linker Script将应用程序的起始地址设置为Bootloader之后的地址例如0x0800 2000。因此应用程序的HEX文件里会包含一个:020000040800F2记录基地址相同但它的数据记录起始地址偏移会是0x2000。这样两个HEX文件虽然基地址都是0x0800 0000但它们的数据记录地址偏移是错开的。合并的任务就是把这两个文件中的所有数据记录类型00提取出来按照其正确的物理地址排序并重新组织成一个新的、包含所有数据记录的HEX文件最后加上统一的结束记录。如果地址发生重叠比如App的某段代码错误地链接到了0x0800 1000而这个地址已经被Bootloader占用合并后的固件在运行时必然会发生不可预知的行为这是最严重的错误之一。3. 合并方案选型与工具实战明白了原理我们来看看具体怎么做。有多种工具和方法可以实现HEX合并我将从最简单到最强大逐一介绍并分析其适用场景和潜在陷阱。3.1 方案一使用srec_cat工具跨平台首选srec_cat是srecord工具集里的瑞士军刀功能极其强大是处理各种固件格式HEX, BIN, S-record等的行业标准工具之一。它跨平台Windows, Linux, macOS可以通过命令行进行精细控制。1. 安装srecord工具Ubuntu/Debian:sudo apt-get install srecordWindows: 可以从SourceForge等网站下载预编译的二进制包或者通过MSYS2、Cygwin环境安装。macOS:brew install srecord2. 基础合并命令假设你的Bootloader文件是bootloader.hex应用程序文件是app.hex想要输出合并后的firmware.hex。srec_cat bootloader.hex -Intel app.hex -Intel -o firmware.hex -Intel这个命令非常简单按顺序读取两个Intel HEX格式的文件然后输出为一个Intel HEX格式的文件。srec_cat会自动处理地址问题如果地址有重叠默认情况下后面的输入文件会覆盖前面的。3. 高级功能与避坑指南地址填充Gap Filling 如果Bootloader和App的地址不是紧密相连中间有空白比如Bootloader实际只用了6KB但我们为它保留了8KB的空间App从8KB后开始直接合并会导致中间有一段地址没有数据。有些烧录器或校验工具会认为这是“空洞”而报错。此时可以用-fill参数填充空白区域通常用0xFFFlash擦除后的状态填充。srec_cat bootloader.hex -Intel -fill 0xFF 0x08000000 0x08002000 app.hex -Intel -o firmware.hex -Intel这个命令在0x08000000到0x08002000的范围内用0xFF填充所有未被bootloader.hex覆盖的地址然后再合并app.hex。生成二进制文件BIN 有时烧录工具或OTA升级包需要纯二进制BIN格式。srec_cat可以轻松转换。srec_cat bootloader.hex -Intel app.hex -Intel -o firmware.bin -Binary但要注意BIN文件没有地址信息。你必须确保从起始地址到结束地址的所有字节都有定义通过填充否则生成的BIN文件会“缺失”中间段长度不对。处理地址重叠冲突 这是最需要警惕的情况。如果两个文件地址有重叠srec_cat默认行为是“后者覆盖前者”这可能不是你想要的。你应该首先检查链接脚本确保编译时地址没有冲突。可以使用srec_info命令查看HEX文件的地址范围srec_info bootloader.hex srec_info app.hex实操心得在自动化构建脚本如Makefile或CI/CD流水线中我强烈推荐使用srec_cat。它的命令行接口稳定参数明确易于集成。务必在脚本中加入地址范围检查的步骤防患于未然。3.2 方案二使用J-Flash工具GUI界面STM32友好如果你主要使用ST的STM32系列并且使用J-Link作为调试器那么SEGGER公司提供的J-Flash软件是一个带有图形界面、非常方便的选择。它不仅能烧录也能合并和修改固件。操作步骤打开J-Flash选择创建新工程并匹配你的芯片型号。点击File-Open data file...首先打开bootloader.hex。数据会被加载到内存缓冲区并在地图视图中显示。再次点击File-Merge data file...选择app.hex。此时会弹出合并选项对话框。关键选项是“Address range handling”Auto 自动处理通常就是覆盖。Preserve old data 保留已加载的数据即bootloader忽略新文件中重叠部分。这是我们通常需要的选项Overwrite with new data 用新数据覆盖。选择Preserve old data点击OK。你会发现App的数据被“叠加”到了Bootloader之后正确的地址上。最后点击File-Save data file as...保存合并后的HEX文件。优点 可视化可以直观地看到地址映射和冲突适合不熟悉命令行的开发者或进行一次性操作。缺点 难以集成到自动化脚本中且是商业软件虽然通常随J-Link提供。3.3 方案三使用Python脚本高度自定义对于有特殊需求或者想将合并逻辑深度集成到内部工具链的情况自己写一个Python脚本是最灵活的方式。Python的intelhex库让这一切变得非常简单。1. 安装intelhex库pip install intelhex2. 编写合并脚本merge_hex.py#!/usr/bin/env python3 import sys from intelhex import IntelHex def main(): if len(sys.argv) 4: print(Usage: python merge_hex.py bootloader.hex app.hex output.hex) sys.exit(1) bootloader_file sys.argv[1] app_file sys.argv[2] output_file sys.argv[3] # 创建IntelHex对象并加载文件 ih_boot IntelHex() ih_app IntelHex() ih_boot.loadhex(bootloader_file) ih_app.loadhex(app_file) # 关键步骤将App的数据合并到Bootloader中。 # overlap 参数决定重叠时的行为 # error - 抛出异常 (推荐用于严格检查) # ignore - 保留旧数据即bootloader # replace - 用新数据替换旧数据 try: ih_boot.merge(ih_app, overlaperror) print(Merge successful. No address overlap detected.) except Exception as e: print(fError during merge: {e}) print(Address overlap detected! Please check your linker scripts.) sys.exit(1) # 写入合并后的HEX文件 ih_boot.write_hex_file(output_file) print(fMerged HEX file saved as: {output_file}) if __name__ __main__: main()3. 使用脚本python merge_hex.py bootloader.hex app.hex firmware.hex脚本的优势完全可控你可以定制任何逻辑比如在合并前自动进行CRC校验、填充特定模式、插入版本信息等。自动化集成可以无缝嵌入到任何基于Python的构建系统如SCons, Meson或CI/CD流程如GitLab CI, Jenkins中。严格的错误检查如上例设置overlaperror可以在合并时立即发现地址冲突而不是生成一个有隐患的固件。4. 合并前后的关键验证与调试合并生成firmware.hex并不意味着万事大吉。在将其烧录到芯片或交付给生产线之前必须进行严格的验证。4.1 验证合并结果查看地址范围 使用srec_info或objdump工具查看合并后文件的地址范围确认是否覆盖了从Bootloader起始到应用程序结束的全部区域且中间没有“空洞”除非你故意留空。srec_info firmware.hex校验和与CRC 虽然HEX文件每行有校验和但整个镜像的完整性通常需要计算CRC32或MD5。你可以用一个小脚本计算合并前后文件的哈希值确保数据没有在合并过程中损坏。一些高级的Bootloader协议也会要求应用程序镜像包含一个尾部的CRC校验值这个值需要在合并后重新计算并填入。向量表检查 对于ARM Cortex-M内核应用程序的起始地址即中断向量表必须正确。合并后应用程序的复位向量通常是第二字指向Reset_Handler的地址必须是它的实际物理地址。你可以用十六进制编辑器或arm-none-eabi-objdump工具查看合并后HEX文件中对应地址的数据进行验证。4.2 烧录与调试避坑指南很多网络热词反映的问题其实就发生在烧录合并后的固件这一步。“cannot load flash programming algorithm!” / “flash download failed”原因1地址超出范围。你为烧录工具如Keil MDK, IAR, STM32CubeProgrammer指定的下载算法Algorithm可能没有覆盖你合并后固件的整个地址范围。特别是如果你将App链接到了非常大的地址例如外部Flash需要确保算法文件.FLM或 .elf支持该区域。解决方法 在IDE的下载配置中检查并编辑Flash算法确保其Start和Size包含了你的固件所有部分。或者使用命令行工具如OpenOCD, pyOCD直接指定整个镜像文件。“no algorithm found for: 00008000h - 00008753h erase skipped!”原因 这个错误明确指出了工具找不到对应地址段的擦除/编程算法。和上一个问题类似是算法配置不匹配。解决方法 同样需要修正Flash算法配置。有时合并后的文件包含了一些位于系统内存、选项字节Option Bytes区域的数据这些区域需要特殊的编程方式并非所有算法都支持。检查你的HEX文件是否不小心包含了这些区域的数据。程序跳转失败Bootloader跳转后App不执行原因 这是合并后最经典的运行时问题。可能原因有App的向量表地址未重映射 Bootloader跳转前需要将MCU的中断向量表偏移寄存器如Cortex-M的VTOR设置为App向量表的起始地址。如果忘记设置中断发生时CPU还是会去Bootloader的区域找向量导致崩溃。时钟或外设未重新初始化 Bootloader可能为了通信修改了系统时钟比如提升了HCLK频率。跳转到App时如果App的初始化代码基于默认时钟配置可能会导致时序错误。稳妥的做法是在跳转前将关键外设特别是时钟、中断控制器恢复到复位状态或者确保App的初始化代码能覆盖所有Bootloader做过的配置。堆栈指针SP未正确加载 App向量表的第一个字是初始堆栈指针。Bootloader的跳转指令必须能正确加载这个值。调试方法 使用调试器单步跟踪Bootloader的跳转指令通常是汇编语句BX或函数指针调用检查跳转前后的寄存器值尤其是PC, SP, VTOR。同时检查App起始地址处的数据确认前两个字SP和Reset_Handler地址是否正确。5. 进阶话题与生产实践5.1 制作带CRC校验的完整固件包在量产中为了确保固件在传输和烧录过程中的完整性我们通常会在合并后的固件末尾附加一个CRC32校验值。Bootloader在升级时会先计算接收到的固件的CRC与附带的校验值比对一致后才执行烧录。操作流程合并Bootloader和App的HEX得到firmware.hex。将firmware.hex转换为纯二进制firmware.bin。使用工具如crc32命令行工具或Python的zlib库计算firmware.bin的CRC32值。将这个4字节的CRC值以小端序Little-Endian追加到firmware.bin的末尾。可选将追加了CRC的BIN文件再转换回HEX格式得到最终用于发布的firmware_with_crc.hex。这样你的发布包就是一个自包含、可校验的完整实体。5.2 自动化构建流水线集成在现代嵌入式开发中固件构建应该是一个一键完成、可重复的过程。我推荐将HEX合并作为构建脚本的最后一步。一个基于Makefile的简单示例# 假设你的工程编译后生成 bootloader.hex 和 app.hex ALL_HEX bootloader.hex app.hex # 最终目标 firmware.hex: $(ALL_HEX) echo Merging HEX files... srec_cat bootloader.hex -Intel app.hex -Intel -fill 0xFF 0x08000000 0x08010000 -o firmware.hex -Intel echo Generating BIN with CRC... # 步骤 HEX转BIN - 计算CRC - 追加CRC - (可选)BIN转回HEX objcopy -I ihex -O binary firmware.hex firmware.bin # ... 计算CRC并追加的命令 ... echo Firmware image ready. .PHONY: clean clean: rm -f firmware.hex firmware.bin在CI/CD服务器如GitLab Runner, Jenkins上每次代码提交或打标签时自动执行这个make命令就能生成可直接用于测试或生产的固件镜像保证了交付物的一致性。5.3 应对复杂内存布局对于一些高级芯片内存布局可能更复杂多块非连续Flash 芯片内部有多块独立的Flash存储区。将部分代码/数据链接到RAM中执行 为了追求极致性能。包含配置信息如Option Bytes 这些数据有特定的地址和格式。在这种情况下合并HEX文件不能简单地使用srec_cat file1.hex file2.hex。你需要为每一块需要编程的区域准备独立的HEX文件或独立的段然后使用srec_cat的地址映射功能将它们“拼凑”到同一个物理地址空间视图下或者直接生成多个独立的烧录文件供烧录器使用。处理这类问题的核心依然是精确理解链接脚本.ld文件和生成的HEX文件的地址分布。工具只是执行者你对内存布局的理解才是成功的关键。合并HEX文件这个看似简单的操作串联起了嵌入式开发中的编译、链接、地址空间管理和生产烧录等多个关键环节。掌握它不仅能让你轻松应对BootloaderApp的经典场景更能让你深入理解固件在芯片中的物理存在形式从而在遇到更复杂的存储管理、固件升级和量产问题时能够游刃有余地从底层原理找到解决方案。希望这篇详尽的拆解能帮你彻底扫清合并之路上的所有障碍。
![[2.11.4] - 2026-02-25](http://pic.xiahunao.cn/yaotu/[2.11.4] - 2026-02-25)
