3. nRF54启动与固件架构解析

nRF54 系列把“上电后先执行谁、再执行谁”这件事做成了可配置、可验证、可回滚的链式结构。理解这条链，是生产测试与自动烧录能否稳定复现的前提：烧录的不只是应用固件，还包括让芯片知道“从哪里启动、如何校验、失败后怎么办”的元数据。若只把 .hex 写进 Flash 而不理解分区与启动配置，产线很容易出现“烧录成功但设备不启动”或“换一批次固件后无法回滚”的问题。

一、启动链：从 Secure Boot 到应用

nRF54 的启动通常分为三级。第一级是芯片内固化的 Secure Boot（安全启动）逻辑，它在上电复位后最先运行，负责建立信任根：检查下一级引导程序的签名或哈希是否合法，决定是否继续启动。第二级是 MCUboot，它是一个可升级的引导加载程序，负责在多个固件映像（image）之间选择、校验并跳转。第三级才是真正的应用固件（Application）。

Secure Boot 与 MCUboot 的分工要分清：Secure Boot 关注“我是否允许 MCUboot 运行”，MCUboot 关注“我该运行哪个应用映像、是否需要交换升级”。在 nRF54 上，Secure Boot 的配置通常与密钥、生命周期状态（如 Secure 与 Debug 的开放程度）绑定，一旦在生产阶段锁定，后续无法随意更改。因此生产烧录必须把 Secure Boot 配置视为一次性、不可逆的关键参数。

二、MCUboot 与分区表

MCUboot 依赖分区表（Partition Table）来定位各个映像。分区表不是代码，而是一段描述 Flash 地址布局的元数据，通常由设备树（DTS）或分区配置文件生成。典型分区包括：

• bootloader：MCUboot 自身占用的区域；
• slot0 / slot1：主应用映像与备用（升级）映像槽；
• scratch：交换升级时用于暂存数据的区域；
• settings / storage：保存升级状态、版本号、回滚标记等；
• secure boot 配置区：保存信任根与启动策略。

分区表一旦确定，应用固件的链接地址、MCUboot 的编译配置、烧录脚本的地址范围都必须与之一致。产线常见错误是：开发阶段改了分区大小，但烧录脚本仍按旧地址写入，导致 MCUboot 找不到有效映像而进入串口恢复模式。

三、固件映像格式与签名

MCUboot 使用的映像不是裸二进制，而是带头部（header）和尾部（trailer）的 MCUboot image 格式。头部包含魔数、映像大小、版本号、加载地址等；尾部包含 TLV（Type-Length-Value）区域，用于存放签名、哈希、密钥等安全信息。生产烧录时，若使用签名映像，必须保证签名密钥与 Secure Boot / MCUboot 中配置的公钥匹配，否则校验失败。

映像的版本号（version）直接影响升级决策：MCUboot 会比较 slot0 与 slot1 的版本，决定是否执行交换。生产烧录若把版本号写错，可能导致设备反复回滚或拒绝升级。因此自动烧录工具应在写入前解析 image header，核对版本、大小与目标槽位。

四、生产烧录对启动配置的影响

生产烧录不是“把固件写进去”这么简单，它至少涉及四类写入对象：分区表、MCUboot、应用映像、以及 Secure Boot 配置。它们之间存在依赖顺序：分区表决定地址，MCUboot 依赖分区表定位映像，应用映像依赖 MCUboot 的校验策略。若烧录顺序或地址错位，启动链会在某一级断裂。

以 nRF54 的典型产线为例，自动烧录工具通常按以下顺序执行：

1. 擦除整片 Flash，确保没有残留的旧分区表或旧映像；
2. 写入分区表与 Secure Boot 配置（若为一次性配置，需确认生命周期状态）；
3. 写入 MCUboot 到 bootloader 分区；
4. 写入签名后的应用映像到 slot0，并写入正确的版本号；
5. 可选：写入 slot1 的初始映像或保留为空；
6. 复位并读取启动日志，确认 MCUboot 校验通过并跳转到应用。

其中第 2 步最容易被忽视。Secure Boot 配置若包含调试端口锁定、密钥哈希等，一旦写入并生效，后续无法通过常规方式修改。因此产线应在写入前用脚本核对配置文件的哈希，避免误烧测试密钥。第 4 步的版本号也必须与产线工单一致：若版本号低于 slot1 中的旧版本，MCUboot 可能拒绝交换，导致升级失败。

五、产线检查要点

为了让启动配置在批量生产中可控，建议在烧录后增加三项检查：第一，读回分区表并核对关键地址与大小；第二，读回 MCUboot 头部，确认版本与编译配置一致；第三，触发一次软复位，通过串口或 RTT 观察 MCUboot 是否打印“Image OK”并跳转。若使用签名映像，还应确认签名验证通过的日志，而不是仅看烧录工具返回成功。

此外，生产烧录工具应支持“配置快照”：把本次烧录使用的分区表、MCUboot 版本、应用版本、签名密钥 ID 记录到工单或本地日志中。这样当现场出现启动异常时，可以快速判断是烧录配置问题还是硬件问题，而不必重新猜测 Flash 内容。

总结来说，nRF54 的启动链是 Secure Boot → MCUboot → 应用，分区表是这条链的地址骨架，映像格式是校验与升级的载体，而生产烧录则是把这三者一次性、按正确顺序、按正确参数写入芯片的过程。理解它们之间的依赖关系，才能让自动烧录从“写进去”升级为“可启动、可验证、可追溯”。