五 B / 无线固件升级 / 01

固件文件怎样变成可以执行的镜像

从 ELF、HEX、BIN 的区别进入 Flash 存储，再明确镜像清单与分区需要记录什么。每项元数据都有启动或检查上的用途。

接续上一篇：上电以后，处理器怎样走到 main

1 · 文件扩展名不能代替内部含义

升级镜像可以在原始内容外增加清单和签名。接收端必须知道接收的是哪种格式，不能把 HEX 文本逐字符写进应用区，或仅凭文件名含 stm32 就确定适配型号。

Flash 按芯片规定的擦除单位清空，再按编程粒度写入；写入可能受对齐、供电、电压和运行位置限制。它有有限擦写次数。只收到几个字节时，不能随意擦掉一个仍包含旧程序的大范围。

真实实现必须引用目标型号参考手册，并验证写入期间当前代码、中断和其他总线访问的约束。电脑模型中的 write 不具有这些物理行为，不能据其成功推出 Flash 升级可靠。

文件模拟的清单概念示意；摘要必须实际计算

{
  "target": "stm32u575-file-demo",
  "version": 2,
  "size": 12,
  "sha256": "由实际内容计算的摘要"
}

target 避免把其他设备内容放进来，version 支持版本策略，size 限定长度，摘要用于核对内容是否一致。真实产品还需来源认证、兼容信息和签名等字段。长度和偏移检查要在每次接收时执行，不能只在传输结束后发现越界。

至少区分启动加载程序、当前可运行应用、更新候选内容与状态记录。两份完整镜像能否容纳，要按实际容量、链接布局和最大升级尺寸计算。还要考虑不同擦除区域、交换空间与保护设置。

不能看到 Flash 剩余一半就推断可以直接双区启动：应用执行地址、中断向量、安全状态以及备份方案都会影响设计。选型时比较成熟启动方案在目标芯片上的适配，而不是照抄另一块板的地址表。

配套 ota_files.py 以普通目录存放两个 slot 文件与 state.json。begin 检查模拟目标、版本和长度，finish 核对完整内容摘要。它没有镜像签名验证，摘要也不证明发布者身份；认证在后面讨论。

动手观察

为一份真实构建产物记录格式、大小、目标与版本，但不擦写设备。再对模拟文件改一个字节，比较摘要，说明这能证明什么、不能证明什么。