1. 嵌入式固件映像文件格式解析AXF、HEX 与 BIN 的本质差异在 STM32 及其他 ARM Cortex-M 系列微控制器的开发实践中工程师每日接触的.axf、.hex和.bin文件表面看都是“能烧进 Flash 运行的代码”但其内部结构、承载信息与工程用途存在根本性差异。这些差异并非编译器随意设计的冗余而是由目标平台的存储架构、调试需求、烧录机制及工具链分工共同决定的工程选择。本文将从编译链接流程出发逐层剖析三类文件的生成逻辑、二进制组织方式、地址语义及实际应用场景帮助硬件工程师与嵌入式开发者建立清晰的技术认知避免在量产烧录、OTA 升级或 JTAG 调试中因格式误用导致功能异常。1.1 C 语言到可执行映像的完整编译链接流程理解文件格式差异的前提是厘清现代嵌入式工具链中“编译-汇编-链接”三阶段的职责边界。以基于 ARM Compilerarmcc或 GNU Arm Embedded Toolchainarm-none-eabi-gcc的 STM32 项目为例典型流程如下预处理Preprocessing处理#include、#define、#ifdef等宏指令生成.i文件。此阶段不涉及语法检查仅做文本替换。编译Compilation将预处理后的 C/C 源码翻译为与目标架构相关的汇编代码.s文件。此阶段进行语法分析、语义检查、优化如-O2但尚未确定变量与函数的最终内存地址。汇编Assembly将汇编代码.s转换为机器指令的二进制目标文件.o或.obj。每个.o文件包含已编码的机器指令Code Section初始化数据Data Section未初始化数据占位符BSS Section符号表Symbol Table记录函数名、全局变量名及其相对偏移重定位表Relocation Table指示链接器如何修正地址引用链接Linking此为关键环节。链接器armlink或ld接收所有.o文件及启动文件startup_stm32f103xb.s、标准库libc.a、CMSIS 库并依据链接脚本.ld或.sct完成地址分配将各 Section 映射到目标存储空间如 Flash 0x08000000SRAM 0x20000000符号解析将.o中的未定义符号如printf绑定到库中具体实现重定位根据分配地址修正所有跳转指令BL,LDR PC, label和数据访问LDR R0, variable中的地址值生成输出产生最终可执行映像——即.axf文件该流程表明.axf是链接器直接输出的“权威版本”而.hex与.bin均为其派生格式生成过程不涉及重新链接仅是内容提取与格式转换。1.2 AXF 文件调试友好的全信息可执行映像.axfARM eXecutable Format是 ARM Compiler 工具链默认生成的 ELFExecutable and Linkable Format变体专为 ARM 架构优化。其核心价值在于同时满足运行与调试双重需求。1.2.1 文件结构与关键段SectionAXF 文件遵循 ELF 标准包含以下关键部分段名称内容地址属性调试相关性.text编译后的机器指令Flash 存储绝对地址如 0x08000000高支持断点、单步执行.data初始化的全局/静态变量Flash 存储启动时拷贝至 RAMFlash 地址 RAM 地址双映射中可查看/修改变量值.bss未初始化的全局/静态变量仅 RAM 地址启动时清零RAM 地址如 0x20000000中可查看变量状态.rodata只读常量如字符串字面量Flash 地址低通常只读.debug_*DWARF 调试信息行号、变量类型、作用域不占用目标机存储极高JTAG/SWD 调试基石.symtab符号表函数/变量名 → 地址映射不占用目标机存储高源码级调试必需工程意义.axf文件体积最大常达数百 KB因其完整保留了调试元数据。MDK-ARMKeil µVision的调试器通过读取.debug_*段将机器指令精确映射回 C 源码行实现设置断点、观察变量、调用栈回溯等功能。若删除.axf仅保留.bin则所有调试能力丧失。1.2.2 生成与使用方式默认生成MDK 中点击 “Build” 或 “Rebuild” 后Objects\project.axf自动产生。调试依赖J-Link、ST-Link 等调试器连接 MCU 时IDE 加载.axf文件解析其符号与调试信息再将.text和.data段写入 Flash/SRAM。非烧录用途.axf本身不可直接用于串口 ISP 或量产编程器烧录因其包含大量调试数据且格式为 ELF 二进制非纯线性映像。1.3 HEX 文件带地址标签的 ASCII 文本映像Intel HEX.hex是一种行业通用的、人类可读的十六进制文件格式由 Intel 公司于 1970 年代制定至今仍被绝大多数烧录工具如 ST-Link Utility、J-Flash、FlyMCU原生支持。其设计初衷是在无统一二进制标准的时代提供一种跨平台、抗传输错误的固件分发格式。1.3.1 文件格式规范与地址语义HEX 文件由多行 ASCII 记录Record组成每行格式为:LLAAAATT[DD...DD]CC字段长度含义示例:1 字符记录起始符:LL2 字符Hex数据字节数Length10→ 16 字节AAAA4 字符Hex数据起始地址Address0000→ 0x0000TT2 字符Hex记录类型Type00Data,01EOF,04Extended Linear Address[DD...]2×LL 字符实际数据十六进制0123456789ABCDEF...CC2 字符Hex校验和256 - (LLAAAATTDD...)A5关键洞察HEX 文件的AAAA字段是16 位地址但实际支持 32 位地址需配合04类型记录Extended Linear Address指定高 16 位。STM32 常见 Flash 起始地址0x08000000在 HEX 中表示为:020000040800F2 :1000000000000000000000000000000000000000EC第一行04类型记录将高 16 位设为0800第二行0000地址即对应0x08000000。1.3.2 生成机制与工程价值MDK 配置在Options for Target → Output → Create HEX File勾选后链接器调用fromelf --i32combined工具从.axf中提取.text、.data段并按地址范围生成多条 HEX 记录。地址驱动烧录烧录工具如 FlyMCU逐行解析 HEX读取AAAA和TT将DD...DD数据写入 MCU 对应地址。此机制天然支持非连续地址烧录如 Bootloader 在0x08000000App 在0x08004000无需用户手动计算偏移。容错性ASCII 编码使其可通过串口、邮件、网页等渠道安全传输校验和CC提供基础完整性校验。1.3.3 局限性体积膨胀每字节数据需 2 字符 ASCII 表示加上地址、长度、类型、校验字段体积约为原始二进制的 3 倍。无调试信息.hex仅含可执行代码与数据不含符号表与调试元数据无法用于源码级调试。解析开销烧录工具需实时解析 ASCII速度低于直接写入二进制。1.4 BIN 文件最精简的线性二进制映像.binBinary文件是三者中最纯粹的格式它是一段连续的、无任何元数据的原始字节流内容即为.axf中.text与.data段按链接脚本指定顺序拼接后的结果。1.4.1 地址隐含性与加载模型BIN 文件的核心特征是地址信息完全隐含它不包含任何地址标记如 HEX 的AAAA。其字节序严格对应链接脚本中定义的存储布局。烧录时工具必须预先被告知起始加载地址Load Address然后将 BIN 文件第一个字节写入该地址第二个字节写入地址1依此类推。例如某 STM32F103 项目链接脚本定义MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 128K RAM (rwx) : ORIGIN 0x20000000, LENGTH 20K } SECTIONS { .text : { *(.text) } FLASH .data : { *(.data) } RAM AT FLASH }则生成的.bin文件前 N 字节.text段从0x08000000开始后 M 字节.data初始化值紧随.text之后位于 Flash 中.bss段不包含在 BIN 中启动代码负责清零关键结论BIN 文件的有效性完全依赖于烧录工具与链接脚本的地址约定一致。若将本应烧录到0x08000000的 BIN 错误地写入0x08001000程序必然崩溃。1.4.2 生成方法与适用场景MDK 命令在Options for Target → User → After Build/Rebuild中添加fromelf --bin --outputObjects\project.bin Objects\project.axfGNU 工具链arm-none-eabi-objcopy -O binary project.elf project.bin核心优势体积最小无冗余字符1:1 映射 Flash 内容适合 OTA 固件包、SD 卡升级、Bootloader 解析。解析极速烧录工具只需顺序写入无地址解析开销ST-Link Programmer 烧录 BIN 比 HEX 快 30%~50%。易于校验可直接对 BIN 文件计算 CRC32/SHA256与 MCU Flash 读出数据比对验证烧录完整性。1.4.3 使用陷阱与规避策略陷阱地址错位如前文所述BIN 无地址信息。常见错误使用不支持指定地址的工具如旧版 FlyMCU烧录 BIN导致程序跑飞。规避方案强制指定地址使用STM32CubeProgrammer时在 “Download” 页明确输入Start Address如0x08000000。Bootloader 集成校验在 Bootloader 中固化校验和如 CRC16启动前验证 APP BIN 的完整性与地址合法性。头信息封装量产固件可自定义 BIN 头Header包含 Magic Number、版本号、CRC、Load Address 等字段由 Bootloader 解析后校验。1.5 三类文件的工程选型决策树场景推荐格式理由注意事项JTAG/SWD 调试开发.axf唯一支持源码级调试、变量观察、调用栈确保调试器配置指向正确.axf串口 ISP如 STM32F103.hexFlyMCU 等工具原生支持地址明确容错性好确认 HEX 地址范围覆盖整个 Flash 分区ST-Link/J-Link 量产烧录.bin体积小、速度快、易集成到自动化脚本必须在烧录工具中显式设置 Start AddressOTA 无线升级.bin最小传输开销便于差分升级bsdiff、加密签名需 Bootloader 支持地址校验与 CRC 验证第三方编程器如 Gang Programmer.hex或.bin查阅编程器手册多数支持两者.hex更通用.bin需确认编程器支持地址设定1.6 实例对比同一项目的三文件分析以一个简化 LED 闪烁工程STM32F103C8T6Flash 0x08000000128KB为例编译后生成文件大小与内容特征如下文件大小关键内容可读性烧录工具兼容性led.axf248 KBELF 头 .text.data.debug_*.symtab二进制需readelf解析MDK、J-Link Commander、OpenOCD调试模式led.hex156 KB多行 ASCII 记录含0x08000000起始地址人类可读可用记事本打开FlyMCU、ST-Link Utility、J-Flash、pyOCDled.bin52 KB纯字节流0x48 0x47 0x00 0xB5 ...二进制十六进制编辑器查看STM32CubeProgrammer、OpenOCDprogram命令、自定义 Bootloader验证实验使用xxd led.bin | head -n 5查看 BIN 前几行可见机器码用cat led.hex | head -n 5查看 HEX 前几行可见:10000000...地址记录用arm-none-eabi-readelf -S led.axf列出所有段及其地址。2. 烧录实践工具链与地址配置详解2.1 STM32CubeProgrammerBIN 文件的可靠烧录STM32CubeProgrammer 是 ST 官方推荐的跨平台烧录工具对 BIN 格式支持最为严谨。其正确操作流程如下连接设备选择ST-LINK作为接口点击Connect。加载文件点击Open file选择led.bin。关键配置在右侧Download区域必须手动输入Start Address如0x08000000。此地址必须与链接脚本中.text段的ORIGIN完全一致。执行烧录点击Download工具将 BIN 数据从0x08000000开始顺序写入 Flash。验证勾选Verify download烧录后自动读回 Flash 数据并与 BIN 比对。错误警示若忽略步骤 3工具默认使用0x00000000将导致代码写入错误地址MCU 无法启动。2.2 FlyMCUHEX 文件的串口 ISP 实践FlyMCU 是针对 STM32 串口 ISP 的经典工具仅支持 HEX 格式不支持 BIN。其工作原理依赖于 HEX 中的地址信息硬件连接PA9TX、PA10RX接 USB-TTL 模块BOOT01NRST 按下后上电进入系统存储器。软件配置选择正确 COM 口、波特率通常 115200芯片型号如STM32F103C8。加载文件点击打开 hex 文件选择led.hex。烧录执行点击开始编程FlyMCU 解析 HEX 每一行的AAAA和TT通过串口协议如 STM32 UART Bootloader 协议将数据写入对应地址。为何 BIN 不支持FlyMCU 的串口协议要求每次写入前发送目标地址而 BIN 文件本身不提供地址工具无法获知应写入何处故报错“No address information in bin file”。2.3 OpenOCD命令行下的灵活控制OpenOCD 提供底层、可编程的烧录能力适用于 CI/CD 自动化。其命令明确区分格式与地址# 烧录 HEX地址由 HEX 自身提供 openocd -f interface/stlink.cfg -f target/stm32f1x.cfg \ -c init; reset halt; stm32f1x mass_erase 0; \ program led.hex verify; reset run; shutdown # 烧录 BIN必须指定地址 openocd -f interface/stlink.cfg -f target/stm32f1x.cfg \ -c init; reset halt; stm32f1x mass_erase 0; \ program led.bin verify 0x08000000; reset run; shutdownprogram led.bin verify 0x08000000中的0x08000000是强制参数缺失则命令失败。3. 高级议题链接脚本、Bootloader 与 OTA 升级3.1 链接脚本.ld/.sct对文件生成的决定性影响.axf、.hex、.bin的内容完全由链接脚本定义。一个典型的双 Bank OTA 链接脚本stm32f103cb_ota.ld可能如下MEMORY { BOOT (rx) : ORIGIN 0x08000000, LENGTH 16K /* Bootloader */ APP1 (rx) : ORIGIN 0x08004000, LENGTH 56K /* Application Bank 1 */ APP2 (rx) : ORIGIN 0x0800C000, LENGTH 56K /* Application Bank 2 */ RAM (rwx) : ORIGIN 0x20000000, LENGTH 20K } SECTIONS { .boot : { *(.boot) } BOOT .app1 : { *(.text) *(.rodata) } APP1 .app2 : { *(.text) *(.rodata) } APP2 .data : { *(.data) } RAM AT APP1 .bss : { *(.bss) } RAM }生成.bin时fromelf会依据.app1的ORIGIN将.text写入0x08004000起始的连续区域。若 Bootloader 需跳转至 App必须读取该.bin的向量表首地址0x08004000处的 MSP 值并设置 SP再跳转至0x08004004Reset Handler。3.2 OTA 升级中的 BIN 文件实践在资源受限的 IoT 设备中OTA 升级固件通常采用 BIN 格式因其最小网络开销52 KB BIN 比 156 KB HEX 节省 2/3 带宽。快速校验MCU 可在接收过程中实时计算 CRC32接收完毕立即验证。Bootloader 可控Bootloader 可将 BIN 直接写入备用 Bank如APP2校验通过后更新跳转标志复位后运行新固件。典型 OTA 流程设备通过 MQTT/HTTP 下载firmware_v2.1.bin至 SPI Flash。Bootloader 读取该 BIN计算 CRC32 并与文件末尾 4 字节比对。校验通过擦除APP2Bank0x0800C000逐页写入 BIN 数据。更新active_bank标志为APP2复位。此过程全程无需地址解析高度可靠。4. 总结格式选择的本质是工程权衡AXF、HEX、BIN 并非简单的“不同后缀”而是嵌入式开发中调试、分发、部署三个阶段的技术载体AXF 是开发态的“活文档”承载着工程师与机器之间的全部语义桥梁HEX 是分发态的“通用信封”以 ASCII 为媒介确保固件在异构环境中的无损传递BIN 是部署态的“终极指令”以最精简的字节流直抵硬件执行单元。一名成熟的嵌入式工程师必须能根据项目阶段调试/测试/量产/维护、资源约束带宽/存储/时间、工具链能力是否支持地址设定及可靠性要求是否需 OTA 校验在三者间做出精准选择。这种选择背后是对编译原理、链接机制、存储架构与烧录协议的深刻理解——这正是专业与业余的根本分野。
AXF、HEX与BIN固件格式本质差异解析
1. 嵌入式固件映像文件格式解析AXF、HEX 与 BIN 的本质差异在 STM32 及其他 ARM Cortex-M 系列微控制器的开发实践中工程师每日接触的.axf、.hex和.bin文件表面看都是“能烧进 Flash 运行的代码”但其内部结构、承载信息与工程用途存在根本性差异。这些差异并非编译器随意设计的冗余而是由目标平台的存储架构、调试需求、烧录机制及工具链分工共同决定的工程选择。本文将从编译链接流程出发逐层剖析三类文件的生成逻辑、二进制组织方式、地址语义及实际应用场景帮助硬件工程师与嵌入式开发者建立清晰的技术认知避免在量产烧录、OTA 升级或 JTAG 调试中因格式误用导致功能异常。1.1 C 语言到可执行映像的完整编译链接流程理解文件格式差异的前提是厘清现代嵌入式工具链中“编译-汇编-链接”三阶段的职责边界。以基于 ARM Compilerarmcc或 GNU Arm Embedded Toolchainarm-none-eabi-gcc的 STM32 项目为例典型流程如下预处理Preprocessing处理#include、#define、#ifdef等宏指令生成.i文件。此阶段不涉及语法检查仅做文本替换。编译Compilation将预处理后的 C/C 源码翻译为与目标架构相关的汇编代码.s文件。此阶段进行语法分析、语义检查、优化如-O2但尚未确定变量与函数的最终内存地址。汇编Assembly将汇编代码.s转换为机器指令的二进制目标文件.o或.obj。每个.o文件包含已编码的机器指令Code Section初始化数据Data Section未初始化数据占位符BSS Section符号表Symbol Table记录函数名、全局变量名及其相对偏移重定位表Relocation Table指示链接器如何修正地址引用链接Linking此为关键环节。链接器armlink或ld接收所有.o文件及启动文件startup_stm32f103xb.s、标准库libc.a、CMSIS 库并依据链接脚本.ld或.sct完成地址分配将各 Section 映射到目标存储空间如 Flash 0x08000000SRAM 0x20000000符号解析将.o中的未定义符号如printf绑定到库中具体实现重定位根据分配地址修正所有跳转指令BL,LDR PC, label和数据访问LDR R0, variable中的地址值生成输出产生最终可执行映像——即.axf文件该流程表明.axf是链接器直接输出的“权威版本”而.hex与.bin均为其派生格式生成过程不涉及重新链接仅是内容提取与格式转换。1.2 AXF 文件调试友好的全信息可执行映像.axfARM eXecutable Format是 ARM Compiler 工具链默认生成的 ELFExecutable and Linkable Format变体专为 ARM 架构优化。其核心价值在于同时满足运行与调试双重需求。1.2.1 文件结构与关键段SectionAXF 文件遵循 ELF 标准包含以下关键部分段名称内容地址属性调试相关性.text编译后的机器指令Flash 存储绝对地址如 0x08000000高支持断点、单步执行.data初始化的全局/静态变量Flash 存储启动时拷贝至 RAMFlash 地址 RAM 地址双映射中可查看/修改变量值.bss未初始化的全局/静态变量仅 RAM 地址启动时清零RAM 地址如 0x20000000中可查看变量状态.rodata只读常量如字符串字面量Flash 地址低通常只读.debug_*DWARF 调试信息行号、变量类型、作用域不占用目标机存储极高JTAG/SWD 调试基石.symtab符号表函数/变量名 → 地址映射不占用目标机存储高源码级调试必需工程意义.axf文件体积最大常达数百 KB因其完整保留了调试元数据。MDK-ARMKeil µVision的调试器通过读取.debug_*段将机器指令精确映射回 C 源码行实现设置断点、观察变量、调用栈回溯等功能。若删除.axf仅保留.bin则所有调试能力丧失。1.2.2 生成与使用方式默认生成MDK 中点击 “Build” 或 “Rebuild” 后Objects\project.axf自动产生。调试依赖J-Link、ST-Link 等调试器连接 MCU 时IDE 加载.axf文件解析其符号与调试信息再将.text和.data段写入 Flash/SRAM。非烧录用途.axf本身不可直接用于串口 ISP 或量产编程器烧录因其包含大量调试数据且格式为 ELF 二进制非纯线性映像。1.3 HEX 文件带地址标签的 ASCII 文本映像Intel HEX.hex是一种行业通用的、人类可读的十六进制文件格式由 Intel 公司于 1970 年代制定至今仍被绝大多数烧录工具如 ST-Link Utility、J-Flash、FlyMCU原生支持。其设计初衷是在无统一二进制标准的时代提供一种跨平台、抗传输错误的固件分发格式。1.3.1 文件格式规范与地址语义HEX 文件由多行 ASCII 记录Record组成每行格式为:LLAAAATT[DD...DD]CC字段长度含义示例:1 字符记录起始符:LL2 字符Hex数据字节数Length10→ 16 字节AAAA4 字符Hex数据起始地址Address0000→ 0x0000TT2 字符Hex记录类型Type00Data,01EOF,04Extended Linear Address[DD...]2×LL 字符实际数据十六进制0123456789ABCDEF...CC2 字符Hex校验和256 - (LLAAAATTDD...)A5关键洞察HEX 文件的AAAA字段是16 位地址但实际支持 32 位地址需配合04类型记录Extended Linear Address指定高 16 位。STM32 常见 Flash 起始地址0x08000000在 HEX 中表示为:020000040800F2 :1000000000000000000000000000000000000000EC第一行04类型记录将高 16 位设为0800第二行0000地址即对应0x08000000。1.3.2 生成机制与工程价值MDK 配置在Options for Target → Output → Create HEX File勾选后链接器调用fromelf --i32combined工具从.axf中提取.text、.data段并按地址范围生成多条 HEX 记录。地址驱动烧录烧录工具如 FlyMCU逐行解析 HEX读取AAAA和TT将DD...DD数据写入 MCU 对应地址。此机制天然支持非连续地址烧录如 Bootloader 在0x08000000App 在0x08004000无需用户手动计算偏移。容错性ASCII 编码使其可通过串口、邮件、网页等渠道安全传输校验和CC提供基础完整性校验。1.3.3 局限性体积膨胀每字节数据需 2 字符 ASCII 表示加上地址、长度、类型、校验字段体积约为原始二进制的 3 倍。无调试信息.hex仅含可执行代码与数据不含符号表与调试元数据无法用于源码级调试。解析开销烧录工具需实时解析 ASCII速度低于直接写入二进制。1.4 BIN 文件最精简的线性二进制映像.binBinary文件是三者中最纯粹的格式它是一段连续的、无任何元数据的原始字节流内容即为.axf中.text与.data段按链接脚本指定顺序拼接后的结果。1.4.1 地址隐含性与加载模型BIN 文件的核心特征是地址信息完全隐含它不包含任何地址标记如 HEX 的AAAA。其字节序严格对应链接脚本中定义的存储布局。烧录时工具必须预先被告知起始加载地址Load Address然后将 BIN 文件第一个字节写入该地址第二个字节写入地址1依此类推。例如某 STM32F103 项目链接脚本定义MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 128K RAM (rwx) : ORIGIN 0x20000000, LENGTH 20K } SECTIONS { .text : { *(.text) } FLASH .data : { *(.data) } RAM AT FLASH }则生成的.bin文件前 N 字节.text段从0x08000000开始后 M 字节.data初始化值紧随.text之后位于 Flash 中.bss段不包含在 BIN 中启动代码负责清零关键结论BIN 文件的有效性完全依赖于烧录工具与链接脚本的地址约定一致。若将本应烧录到0x08000000的 BIN 错误地写入0x08001000程序必然崩溃。1.4.2 生成方法与适用场景MDK 命令在Options for Target → User → After Build/Rebuild中添加fromelf --bin --outputObjects\project.bin Objects\project.axfGNU 工具链arm-none-eabi-objcopy -O binary project.elf project.bin核心优势体积最小无冗余字符1:1 映射 Flash 内容适合 OTA 固件包、SD 卡升级、Bootloader 解析。解析极速烧录工具只需顺序写入无地址解析开销ST-Link Programmer 烧录 BIN 比 HEX 快 30%~50%。易于校验可直接对 BIN 文件计算 CRC32/SHA256与 MCU Flash 读出数据比对验证烧录完整性。1.4.3 使用陷阱与规避策略陷阱地址错位如前文所述BIN 无地址信息。常见错误使用不支持指定地址的工具如旧版 FlyMCU烧录 BIN导致程序跑飞。规避方案强制指定地址使用STM32CubeProgrammer时在 “Download” 页明确输入Start Address如0x08000000。Bootloader 集成校验在 Bootloader 中固化校验和如 CRC16启动前验证 APP BIN 的完整性与地址合法性。头信息封装量产固件可自定义 BIN 头Header包含 Magic Number、版本号、CRC、Load Address 等字段由 Bootloader 解析后校验。1.5 三类文件的工程选型决策树场景推荐格式理由注意事项JTAG/SWD 调试开发.axf唯一支持源码级调试、变量观察、调用栈确保调试器配置指向正确.axf串口 ISP如 STM32F103.hexFlyMCU 等工具原生支持地址明确容错性好确认 HEX 地址范围覆盖整个 Flash 分区ST-Link/J-Link 量产烧录.bin体积小、速度快、易集成到自动化脚本必须在烧录工具中显式设置 Start AddressOTA 无线升级.bin最小传输开销便于差分升级bsdiff、加密签名需 Bootloader 支持地址校验与 CRC 验证第三方编程器如 Gang Programmer.hex或.bin查阅编程器手册多数支持两者.hex更通用.bin需确认编程器支持地址设定1.6 实例对比同一项目的三文件分析以一个简化 LED 闪烁工程STM32F103C8T6Flash 0x08000000128KB为例编译后生成文件大小与内容特征如下文件大小关键内容可读性烧录工具兼容性led.axf248 KBELF 头 .text.data.debug_*.symtab二进制需readelf解析MDK、J-Link Commander、OpenOCD调试模式led.hex156 KB多行 ASCII 记录含0x08000000起始地址人类可读可用记事本打开FlyMCU、ST-Link Utility、J-Flash、pyOCDled.bin52 KB纯字节流0x48 0x47 0x00 0xB5 ...二进制十六进制编辑器查看STM32CubeProgrammer、OpenOCDprogram命令、自定义 Bootloader验证实验使用xxd led.bin | head -n 5查看 BIN 前几行可见机器码用cat led.hex | head -n 5查看 HEX 前几行可见:10000000...地址记录用arm-none-eabi-readelf -S led.axf列出所有段及其地址。2. 烧录实践工具链与地址配置详解2.1 STM32CubeProgrammerBIN 文件的可靠烧录STM32CubeProgrammer 是 ST 官方推荐的跨平台烧录工具对 BIN 格式支持最为严谨。其正确操作流程如下连接设备选择ST-LINK作为接口点击Connect。加载文件点击Open file选择led.bin。关键配置在右侧Download区域必须手动输入Start Address如0x08000000。此地址必须与链接脚本中.text段的ORIGIN完全一致。执行烧录点击Download工具将 BIN 数据从0x08000000开始顺序写入 Flash。验证勾选Verify download烧录后自动读回 Flash 数据并与 BIN 比对。错误警示若忽略步骤 3工具默认使用0x00000000将导致代码写入错误地址MCU 无法启动。2.2 FlyMCUHEX 文件的串口 ISP 实践FlyMCU 是针对 STM32 串口 ISP 的经典工具仅支持 HEX 格式不支持 BIN。其工作原理依赖于 HEX 中的地址信息硬件连接PA9TX、PA10RX接 USB-TTL 模块BOOT01NRST 按下后上电进入系统存储器。软件配置选择正确 COM 口、波特率通常 115200芯片型号如STM32F103C8。加载文件点击打开 hex 文件选择led.hex。烧录执行点击开始编程FlyMCU 解析 HEX 每一行的AAAA和TT通过串口协议如 STM32 UART Bootloader 协议将数据写入对应地址。为何 BIN 不支持FlyMCU 的串口协议要求每次写入前发送目标地址而 BIN 文件本身不提供地址工具无法获知应写入何处故报错“No address information in bin file”。2.3 OpenOCD命令行下的灵活控制OpenOCD 提供底层、可编程的烧录能力适用于 CI/CD 自动化。其命令明确区分格式与地址# 烧录 HEX地址由 HEX 自身提供 openocd -f interface/stlink.cfg -f target/stm32f1x.cfg \ -c init; reset halt; stm32f1x mass_erase 0; \ program led.hex verify; reset run; shutdown # 烧录 BIN必须指定地址 openocd -f interface/stlink.cfg -f target/stm32f1x.cfg \ -c init; reset halt; stm32f1x mass_erase 0; \ program led.bin verify 0x08000000; reset run; shutdownprogram led.bin verify 0x08000000中的0x08000000是强制参数缺失则命令失败。3. 高级议题链接脚本、Bootloader 与 OTA 升级3.1 链接脚本.ld/.sct对文件生成的决定性影响.axf、.hex、.bin的内容完全由链接脚本定义。一个典型的双 Bank OTA 链接脚本stm32f103cb_ota.ld可能如下MEMORY { BOOT (rx) : ORIGIN 0x08000000, LENGTH 16K /* Bootloader */ APP1 (rx) : ORIGIN 0x08004000, LENGTH 56K /* Application Bank 1 */ APP2 (rx) : ORIGIN 0x0800C000, LENGTH 56K /* Application Bank 2 */ RAM (rwx) : ORIGIN 0x20000000, LENGTH 20K } SECTIONS { .boot : { *(.boot) } BOOT .app1 : { *(.text) *(.rodata) } APP1 .app2 : { *(.text) *(.rodata) } APP2 .data : { *(.data) } RAM AT APP1 .bss : { *(.bss) } RAM }生成.bin时fromelf会依据.app1的ORIGIN将.text写入0x08004000起始的连续区域。若 Bootloader 需跳转至 App必须读取该.bin的向量表首地址0x08004000处的 MSP 值并设置 SP再跳转至0x08004004Reset Handler。3.2 OTA 升级中的 BIN 文件实践在资源受限的 IoT 设备中OTA 升级固件通常采用 BIN 格式因其最小网络开销52 KB BIN 比 156 KB HEX 节省 2/3 带宽。快速校验MCU 可在接收过程中实时计算 CRC32接收完毕立即验证。Bootloader 可控Bootloader 可将 BIN 直接写入备用 Bank如APP2校验通过后更新跳转标志复位后运行新固件。典型 OTA 流程设备通过 MQTT/HTTP 下载firmware_v2.1.bin至 SPI Flash。Bootloader 读取该 BIN计算 CRC32 并与文件末尾 4 字节比对。校验通过擦除APP2Bank0x0800C000逐页写入 BIN 数据。更新active_bank标志为APP2复位。此过程全程无需地址解析高度可靠。4. 总结格式选择的本质是工程权衡AXF、HEX、BIN 并非简单的“不同后缀”而是嵌入式开发中调试、分发、部署三个阶段的技术载体AXF 是开发态的“活文档”承载着工程师与机器之间的全部语义桥梁HEX 是分发态的“通用信封”以 ASCII 为媒介确保固件在异构环境中的无损传递BIN 是部署态的“终极指令”以最精简的字节流直抵硬件执行单元。一名成熟的嵌入式工程师必须能根据项目阶段调试/测试/量产/维护、资源约束带宽/存储/时间、工具链能力是否支持地址设定及可靠性要求是否需 OTA 校验在三者间做出精准选择。这种选择背后是对编译原理、链接机制、存储架构与烧录协议的深刻理解——这正是专业与业余的根本分野。
