HEX文件合并：Bootloader与APP集成

原创于 2025-11-04 16:16:28 发布 · 638 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#HEX合并 # Bootloader # APP # SRecord # intelhex # 固件升级 # FOTA # 嵌入式开发

AI助手已提取文章相关产品：

实现Bootloader与APP程序HEX文件的快速合并

在嵌入式系统开发中，我们常常会遇到这样的场景：产品需要支持远程固件升级（FOTA），于是架构上采用了 Bootloader + 应用程序的双阶段设计。这本是行业标准做法，但当真正进入量产或持续集成阶段时，一个看似简单的问题却频繁浮现——如何安全、高效地将两个独立编译生成的 HEX 文件合并成一个完整的固件镜像？

你可能已经试过手动拼接文本文件，或者直接烧录多个文件到不同地址。但在实际项目中，这种“土办法”极易引发灾难性后果：地址重叠导致程序跑飞、遗漏段落造成启动失败、校验和错误让烧录工具拒载……更别提在 CI/CD 流水线里实现自动化构建了。

其实，这个问题的本质并不在于“能不能做”，而在于 怎么做才可靠、可重复、可维护 。真正的挑战不是技术本身，而是整个流程的工程化控制能力。

现代 MCU 开发中广泛使用的 Intel HEX 格式，是一种带地址信息的文本型二进制容器。它不像 BIN 文件那样只是裸数据流，而是由一系列记录组成，每条记录都包含长度、地址、类型和校验和等字段。典型的格式如下：

:llaaaatt[dd...]cc

比如：

:020000040800F2
:10000000214601360121470136007EFE09D2190140
:00000001FF

第一行 :04 类型表示扩展线性地址，设置基址为 0x08000000 ；第二行为实际代码数据；最后一行是结束标记。正是这种结构化的文本格式，使得我们可以用脚本对多个 HEX 文件进行解析与重组。

然而问题来了：如果你有两个 HEX 文件，一个从 0x08000000 开始，另一个从 0x08004000 起步，能否直接把它们的内容拼在一起？答案是否定的。因为每个文件内部都有自己的地址控制记录，如果简单追加，可能会导致地址错位、重复定义甚至覆盖关键区域。

这就引出了我们需要的核心能力： 在一个统一的虚拟地址空间下，安全地合并多段内存映像，并保留正确的地址上下文和终止标志 。

幸运的是，已经有成熟的工具链可以解决这一问题。其中最值得推荐的就是 SRecord —— 一套轻量级但功能强大的命令行工具集，专为处理嵌入式目标文件而生。

使用 srec_cat 命令，你可以轻松完成合并操作。例如：

srec_cat bootloader.hex -intel \
         app.hex -intel \
         -o firmware_merged.hex -intel

这条命令背后的工作机制远比看起来复杂：它会逐行解析两个文件的所有记录，提取出有效数据及其对应地址，映射到统一的 32 位地址空间中，自动处理 :04 扩展地址记录，并按地址排序输出新的 HEX 文件。更重要的是，它能检测潜在的地址冲突并给出警告。

但这还不是全部。在真实项目中，Flash 区域之间往往存在空隙。例如 Bootloader 占用前 16KB，APP 从 0x08004000 开始，中间这段空白如果不填充，在某些编程器或分析工具眼中会被视为“未初始化”，从而影响一致性判断。这时就可以借助 -fill 参数显式补全：

srec_cat bootloader.hex -intel \
         -fill 0xFF 0x08000000 0x08004000 \
         app.hex -intel \
         -o firmware_merged.hex -intel

这里的 0xFF 是 Flash 擦除后的默认值，填充后不仅逻辑清晰，还能避免因随机数据带来的安全隐患。

而对于 OTA 包生成等特殊需求，还可以进一步裁剪内容。比如排除 APP 头部若干字节（如跳转指令或签名区）：

srec_cat app.hex -intel \
         -exclude 0x08004000 0x08004010 \
         -o app_trimmed.hex -intel

这些操作都可以无缝集成进 Makefile 或 CMake 构建系统，实现一键生成完整固件：

MERGE_TOOL := srec_cat

firmware.hex: bootloader.hex app.hex
    $(MERGE_TOOL) bootloader.hex -intel app.hex -intel -o $@ -intel
    @echo "✅ 固件合并完成: $@"

当然，也有些团队出于环境限制或定制化需求，选择不依赖外部工具，而是通过 Python 自主实现 HEX 解析与合并逻辑。这时候， intelhex 这个第三方库就成了利器。

只需安装：

pip install intelhex

然后编写一个简洁的合并脚本即可：

from intelhex import IntelHex
import sys

def merge_hex_files(bl_path, app_path, output_path):
    merged = IntelHex()

    # 加载 Bootloader
    try:
        ih_boot = IntelHex(bl_path)
        print(f"[INFO] 成功加载 Bootloader: {bl_path}")
        if not merged.merge(ih_boot, overlap='error'):
            raise ValueError("Bootloader 地址冲突")
    except Exception as e:
        print(f"[ERROR] 加载 Bootloader 失败: {e}")
        sys.exit(1)

    # 加载 APP
    try:
        ih_app = IntelHex(app_path)
        print(f"[INFO] 成功加载 APP: {app_path}")

        app_min_addr = ih_app.minaddr()
        boot_max_addr = ih_boot.maxaddr()
        if app_min_addr <= boot_max_addr:
            print(f"[WARN] APP 起始地址 {hex(app_min_addr)} ≤ Bootloader 结束地址 {hex(boot_max_addr)}，可能存在重叠！")

        if not merged.merge(ih_app, overlap='replace'):
            print("[ERROR] APP 合并失败")
            sys.exit(1)
    except Exception as e:
        print(f"[ERROR] 加载 APP 失败: {e}")
        sys.exit(1)

    # 输出结果
    try:
        merged.write_hex_file(output_path)
        print(f"[SUCCESS] 合并完成，输出至: {output_path}")
    except Exception as e:
        print(f"[ERROR] 写入输出文件失败: {e}")
        sys.exit(1)

if __name__ == "__main__":
    if len(sys.argv) != 4:
        print("用法: python merge_hex.py <bootloader.hex> <app.hex> <output.hex>")
        sys.exit(1)

    merge_hex_files(sys.argv[1], sys.argv[2], sys.argv[3])

这个脚本虽然短小，却具备完整的错误捕获、日志输出和地址检查机制。更重要的是，它可以轻松嵌入 GitHub Actions、Jenkins 等 CI 平台，配合单元测试验证合并正确性，真正实现“构建即可信”。

值得一提的是，在实际系统设计中，Flash 布局必须提前规划清楚。典型配置如下：

区域	起始地址	大小	用途
Bootloader	0x08000000	16KB	引导、升级、恢复
APP Vector Table	0x08004000	256B	中断向量表重映射
Main APP	0x08004100	~112KB	用户功能代码
Reserved / OTA Buffer	0x08020000	64KB	接收新固件