1. 单片机烧录用的 hex 文件到底长什么样从一行记录看懂 Intel HEX 格式解析如果你手里有一块 STM32、GD32、N76E003 或者 51 单片机量产烧录时大概率会拿到一个.hex文件。它和.bin最大的区别是bin 只有纯数据烧录器必须提前知道往哪个地址写而 hex 文件每一行都自带地址信息烧录器逐行读就能把数据放到正确位置。这也是为什么很多烧录工具默认优先吃 hex。Intel HEX 是一种纯文本格式用记事本、Notepad、VS Code 都能直接打开。你会看到类似这样的内容:1000000000800020C1000008C5000008C9000008A0 :100010000000000000000000000000000000000000 :0400000508000000EF :00000001FF每一行都以英文冒号:开头这叫 RecordMark记录起始符。冒号后面是一串十六进制字符按字节拆开就是一条完整记录。一条记录固定由 5 个部分组成数据长度、装载地址、记录类型、有效数据、校验和。理解这 5 个字段你就能独立读懂任意一个 hex 文件不用再依赖烧录软件的黑盒提示。这篇文章面向正在做单片机烧录、上位机开发、Bootloader 升级的工程师也适合刚接触嵌入式、想搞清楚 hex 文件格式解析的初学者。我会逐行拆解字段含义给出一份可复制的解析对照表再写一个能直接跑的校验和验证脚本最后用真实烧录文件带你逐行核对。读完你至少能做到三件事手动算出一行的校验和、判断某个 hex 文件是否被改坏、用脚本批量验证整个文件。先记住一个核心结论Intel HEX 的校验和规则是「所有字节累加后取低 8 位结果必须为 0」。这一条贯穿全文后面所有排错都围绕它展开。2. 逐字段拆解 hex 记录数据长度、地址、记录类型与校验和计算逻辑拿第一行:1000000000800020C1000008C5000008C9000008A0来拆。去掉冒号后每两个十六进制字符是一个字节字段位置字节内容含义说明第 1 字节10数据长度0x10 16表示后面有 16 字节有效数据第 2-3 字节0000装载地址本行数据写入的偏移地址 0x0000第 4 字节00记录类型00 表示数据记录第 5-20 字节00800020...0008有效数据共 16 字节就是要烧进 Flash 的内容第 21 字节A0校验和前面所有字节累加取低 8 位应为 0记录类型一共 6 种实际烧录文件里最常见的是 00、01、04 三种类型值名称作用00数据记录携带要写入 Flash 的真实数据01文件结束标记 hex 文件到此结束固定为:00000001FF02扩展段地址用段地址方式扩展寻址较少见03开始段地址指定程序入口一般 51 单片机用04扩展线性地址用线性方式扩展高 16 位地址STM32 常见05开始线性地址指定 32 位程序入口地址校验和的计算逻辑把「数据长度 地址高字节 地址低字节 记录类型 所有数据字节」逐字节相加取结果的低 8 位再用0x100减去这个低 8 位得到校验和。等价说法是把包括校验和在内的所有字节相加低 8 位必须等于 0。以第一行为例累加过程如下10 00 00 00 00 80 00 20 C1 00 00 08 C5 00 00 08 C9 00 00 08 0x360 0x360 0xFF 0x60 0x100 - 0x60 0xA0算出来正好是行尾的A0说明这一行没被改坏。再看结束行:00000001FF长度 00、地址 0000、类型 01、无数据累加000000010x010x100-0x010xFF和行尾一致。扩展线性地址类型 04是理解大容量单片机 hex 的关键。比如 STM32F103 的 Flash 从 0x08000000 开始但单条记录的地址字段只有 16 位最大 0xFFFF装不下 0x08000000。于是 hex 文件会先出现一行:020000040800F2其中数据是0800表示基地址 0x0800 16 0x08000000。在这行之后、下一个类型 04 出现之前所有数据记录的实际地址 基地址 记录地址字段。举个例子:020000040800F2 :1000000000800020C1000008C5000008C9000008A0 :100010000000000000000000000000000000000000第一行设定基地址 0x08000000。第二行地址字段 0x0000实际写入 0x08000000。第三行地址字段 0x0010实际写入 0x08000010。这样就能覆盖整个 0x08000000 起始的 Flash 空间。3. 可复制的 hex 解析对照表与校验和验证脚本光看理论不够我准备了一份可以直接用的解析对照表以及一个 Python 校验脚本。你把它保存成hex_check.py就能批量验证任意 hex 文件。先看对照表建议收藏行内容示例长度地址类型数据校验和实际写入地址:1000000000800020...A01000000016 字节A0基地址0x0000:100010000000...001000100016 字节00基地址0x0010:020000040800F2020000040800F2设定基地址 0x08000000:0400000508000000EF0400000508000000EF入口地址 0x08000000:00000001FF00000001无FF文件结束下面是校验和验证脚本逐行读取 hex 文件检查每行校验和是否为 0并打印解析结果#!/usr/bin/env python3 # -*- coding: utf-8 -*- import sys def parse_line(line): line line.strip() if not line or not line.startswith(:): return None raw line[1:] if len(raw) % 2 ! 0: return {error: 字符数为奇数格式错误, line: line} data bytes.fromhex(raw) length data[0] addr (data[1] 8) | data[2] rtype data[3] payload data[4:4 length] checksum data[4 length] total sum(data) 0xFF return { line: line, length: length, addr: addr, type: rtype, data: payload.hex().upper(), checksum: checksum, sum_ok: total 0, } def main(path): base 0 with open(path, r, encodingutf-8, errorsignore) as f: for idx, line in enumerate(f, 1): r parse_line(line) if r is None: continue if error in r: print(f第{idx}行 错误: {r[error]}) continue if r[type] 0x04: base int(r[data], 16) 16 real_addr base r[addr] if r[type] 0x00 else None flag OK if r[sum_ok] else 校验失败 print(f第{idx}行 类型{r[type]:02X} 长度{r[length]:02X} f地址{r[addr]:04X} 实际地址{real_addr} f校验和{r[checksum]:02X} [{flag}]) if r[type] 0x01: print(文件结束) break if __name__ __main__: main(sys.argv[1] if len(sys.argv) 1 else firmware.hex)运行方式python hex_check.py firmware.hex输出会逐行告诉你类型、地址、实际写入地址和校验结果。如果某行显示「校验失败」说明文件被改坏或复制时丢了字符。如果你想把解析结果接到自己的上位机里用 TaoToken 的模型对话能力快速生成不同语言的解析代码也很省事比如让它把上面的 Python 逻辑翻译成 C# 或 C再对照本文的字段表核对。需要的话可以从 https://taotoken.net/api 接入配合 https://taotoken.net/api-keys 拿到的 Key 使用。4. 用真实烧录文件逐行核对验证请求与成功结果理论讲完拿一个真实的 STM32 工程 hex 文件来核对。假设文件开头是:020000040800F2 :1000000000800020C1000008C5000008C9000008A0 :100010000000000000000000000000000000000000 :100020000000000000000000000000000000000000 :0400000508000000EF :00000001FF第一步确认第一行:020000040800F2。长度 02地址 0000类型 04数据 0800校验和 F2。累加0200000408000x0E0x100-0x0E0xF2正确。这行把基地址设为 0x08000000。第二步看第二行:1000000000800020...A0。类型 00地址 0000实际写入 0x08000000。这 16 字节是中断向量表开头前 4 字节00 80 00 20小端解读为 0x20008000正是栈顶地址接着C1 00 00 08是复位向量 0x080000C1。这说明文件确实是 STM32 的固件。第三步看:0400000508000000EF。类型 05数据 08000000表示程序入口地址。校验累加0400000508000000000x110x100-0x110xEF正确。第四步看结束行:00000001FF。类型 01校验和 FF正确。到这里整个文件结构就核对完了。用脚本跑一遍成功输出类似第1行 类型04 长度02 地址0000 实际地址None 校验和F2 [OK] 第2行 类型00 长度10 地址0000 实际地址0x08000000 校验和A0 [OK] 第3行 类型00 长度10 地址0010 实际地址0x08000010 校验和00 [OK] 第4行 类型00 长度10 地址0020 实际地址0x08000020 校验和00 [OK] 第5行 类型05 长度04 地址0000 实际地址None 校验和EF [OK] 第6行 类型01 长度00 地址0000 实际地址None 校验和FF [OK] 文件结束所有行都是 OK说明文件完整。如果某行校验失败脚本会明确标出你就能定位到具体哪一行被改坏。这里有个实用技巧很多烧录失败并不是 hex 文件本身的问题而是烧录器把类型 04 的基地址忽略了导致数据被写到 0x00000000 而不是 0x08000000。遇到「烧进去不运行」的情况先确认烧录器是否正确处理了类型 04 记录。5. 本篇常见错误排查校验失败、地址错乱与烧录器报错实际工作中hex 文件相关的报错集中在几类我按真实报错信息整理成排查表。第一类校验和错误。烧录器提示checksum error at line N或record checksum mismatch。原因通常是文件在传输、复制、Git 合并时被改动或者用文本编辑器保存时改了换行符。排查方法用第 3 节的脚本跑一遍定位到具体行对比原始文件。注意有些编辑器会自动在文件末尾加空行空行会被解析器跳过一般不影响但如果把某行的字符删了一个校验必然失败。第二类地址错乱。烧录器提示address out of range或数据写到了错误区域。常见原因是类型 04 记录被忽略或者类型 02 和类型 04 混用。类型 02 是段地址基地址 段值 4类型 04 是线性地址基地址 值 16。两者计算方式不同不能混。STM32 一般只用类型 04。第三类文件结束记录缺失。烧录器提示no end of file record或一直等待。Intel HEX 规范要求文件必须以:00000001FF结尾。如果这行丢了有些烧录器会一直读不到结束标志。检查文件最后一行即可。第四类OAuth 或本地代理相关报错。如果你在用某些云端工具或本地服务解析 hex可能遇到local proxy failed或OAuth token expired。这类报错和 hex 格式无关是工具链的鉴权问题。检查你的 API Key 是否过期重新生成即可。用 TaoToken 的话可以在 https://taotoken.net/api-keys 重新签发 Key再在工具里更新配置。第五类reading choices类报错。这通常出现在用脚本或工具批量处理多个 hex 文件时工具在读取选项或配置时失败。检查输入路径是否正确、文件是否有读权限、文件编码是否为 UTF-8 或 ASCII。hex 文件本身是纯 ASCII如果被存成 UTF-8 with BOM开头会多出EF BB BF导致第一行解析失败。用 VS Code 另存为「UTF-8 无 BOM」即可。第六类烧录后程序不运行。hex 校验全过但单片机没反应。这时候要检查类型 05 的入口地址是否正确以及类型 04 的基地址是否和芯片实际 Flash 起始地址一致。比如 STM32F103 是 0x08000000STM32F407 也是 0x08000000但有些国产芯片是 0x00000000 映射。确认芯片手册里的 Flash 起始地址。排查时建议按顺序来先跑校验脚本确认文件完整再看类型 04 基地址再看类型 05 入口最后看烧录器配置。这样能覆盖 90% 以上的问题。6. 把 hex 解析接进你的烧录工具链从手动核对到自动化手动核对适合排查单个文件但量产或持续集成时你需要把 hex 解析自动化。思路很简单在烧录前加一道校验关卡用脚本验证 hex 文件完整性校验失败就直接阻断烧录流程。一个典型的 CI 流程可以这样设计python hex_check.py build/firmware.hex hex_report.txt if grep -q 校验失败 hex_report.txt; then echo hex 文件校验失败终止烧录 exit 1 fi echo hex 文件校验通过开始烧录这样每次构建产物都会先过一遍校验避免把损坏的文件烧进芯片。对于 Bootloader 升级场景还可以在解析时提取类型 00 的数据按实际地址重组出 bin 文件再通过串口或 CAN 发送给目标板。如果你想让工具链更智能比如自动识别不同芯片的基地址、自动生成烧录配置可以借助大模型来辅助生成解析逻辑。TaoToken 的模型对话接口支持把 hex 解析需求直接转成代码适合快速验证思路。接入地址是 https://taotoken.net/api配合 https://taotoken.net/doc 里的文档说明使用。对于长期做嵌入式工具开发的团队Coding Plan 能覆盖日常的代码生成和调试需求入口在 https://taotoken.net/coding-plan。最后留一个实用习惯每次拿到新的 hex 文件先看最后一行是不是:00000001FF再看有没有类型 04 记录最后跑一遍校验脚本。这三步花不了一分钟但能帮你避开绝大多数烧录翻车现场。