AXF 文件: 是编译器(如 ARM GCC, Keil, IAR)生成的调试文件。它包含最终的可执行机器码、调试信息(变量名、函数名、行号等)和丰富的元数据(如段地址)。主要用于调试。
HEX 文件: 是一种带有地址信息的标准烧录文件。它包含可执行机器码,并且每条记录都标明了其应该被烧录到的内存地址。格式是文本形式的,可读。
BIN 文件: 是一种纯二进制镜像文件。它只包含最原始的机器码数据,没有任何地址信息。它是体积最小的输出格式。
1. AXF 文件
它是编译和链接的最终输出。 当你点击"Build"或"Compile"时,编译器生成的目标文件(.o)被链接器合并,最终生成的就是 AXF 文件(在GCC环境下通常是 .elf 文件,与 .axf 本质相同)。
它是“最富有”的文件,包含了调试所需的一切。当你在 Keil 或 IAR 中进行单步调试、查看变量、设置断点时,IDE 正是在读取 AXF 文件中的调试信息来匹配机器码和你的源代码。
在产品发布时,通常不会发布 AXF 文件,因为它体积庞大且可能泄露源代码结构。
2. HEX 文件
它是一种标准化的交换格式。 因为它包含地址信息,所以烧录器(编程器)知道该把哪一段数据放到存储器的哪个地址。例如,它明确区分哪部分是代码(应该烧录到 0x08000000 的 Flash),哪部分是数据(应该烧录到 0x20000000 的 RAM)。
它的结构是文本行,每行以冒号(:)开始,后面跟着字节数、地址、记录类型、数据字节和校验和。
示例::10010000214601360121470136007EFE09D2190140
由于有地址信息,它可以表示不连续的二进制数据块,这对于有中断向量表等特定地址要求的微控制器程序非常有用。
3. BIN 文件
它是“最纯粹”的机器码映像。 它仅仅是将 AXF 文件中需要烧录到存储器的部分(通常是 .text, .data 段)提取出来,按顺序拼接成一个连续的数据流。
它本身不包含任何地址信息。 这意味着你在烧录 BIN 文件时,必须手动指定烧录的起始地址。例如,告诉烧录工具将这个 BIN 文件烧录到 STM32 Flash 的起始地址 0x08000000。
因为它没有冗余的地址、记录类型、校验和等文本信息,所以它的体积最小,在通过网络进行 OTA 固件升级时,可以节省带宽。
下图清晰地展示了从源代码到可烧录文件的完整流程,以及各文件之间的关系:
如何选择?
开发阶段: 使用 AXF 进行调试。
生产烧录:
如果烧录工具支持且方便,HEX 是更安全省事的选择,因为地址信息是自包含的。
如果对文件大小非常敏感(如OTA),或者烧录工具/流程要求,则使用 BIN,但务必记住其烧录起始地址。
OTA 升级: 通常使用 BIN 文件,以最小化传输数据量。升级程序会知道将接收到的 BIN 数据写入到存储器的哪个位置。