4. 刷写升级基础
在 RH850 这类车规级 MCU 的 Bootloader 工程中，刷写升级并不是“把新固件写进去”这么简单，它是一套由存储分区、通信协议、校验机制、安全策略和行业标准共同约束的完整系统。理解这套基础，是后续设计 Bootloader 状态机、CAN/UDS 刷写流程以及安全启动机制的前提。
一、刷写升级的核心原理
刷写升级的本质，是在目标 ECU 上把旧的应用程序（App）替换为新的固件镜像，并保证替换后系统能够正确启动。RH850 通常将 Flash 划分为 Bootloader 区、App 区、参数/标定区，部分方案还会保留备份区（Backup）和升级标志区（Update Flag）。
上电后，Bootloader 先运行，判断升级标志是否有效：若有效，则进入刷写模式，通过通信接口接收新固件并写入 App 区；若无效，则跳转到 App 执行。刷写过程中，新固件通常按“块（Block）”或“段（Segment）”传输，每块写入前擦除对应 Flash 扇区，写入后立即做校验，确保数据完整。
二、通信接口与协议选择
RH850 刷写升级常用的通信接口包括 CAN、CAN FD、LIN、FlexRay 和以太网（DoIP）。在车载诊断场景中，CAN/CAN FD 配合 UDS（ISO 14229）是最主流的组合；LIN 多用于低成本节点；以太网则用于高带宽刷写，如智能座舱或域控制器。
UDS 刷写涉及几个关键服务：0x10 会话控制、0x27 安全访问、0x34 请求下载、0x36 传输数据、0x37 请求退出传输、0x31 例程控制、0x11 ECU 复位。Bootloader 需要实现这些服务的服务端逻辑，并配合 P2/P2* 超时参数保证通信可靠性。
典型 UDS 刷写服务序列：
10 03 → 进入扩展会话
27 01 / 27 02 → 安全访问（Seed/Key）
31 01 FF00 → 擦除 Flash 例程
34 00 44 ... → 请求下载（指定地址与长度）
36 01 ... → 传输数据块
37 01 → 退出传输
31 01 FF01 → 校验例程
11 01 → ECU 复位
三、升级流程与状态迁移
一个完整的刷写升级流程通常分为：预编程、编程、后编程三个阶段。预编程阶段检查车辆条件、读取版本、进入扩展会话；编程阶段执行安全访问、擦除、下载、校验；后编程阶段复位 ECU、清除故障码、验证版本。
下图展示了 RH850 Bootloader 刷写升级的典型数据流与状态迁移关系，涵盖诊断仪、Bootloader、Flash 分区以及安全校验之间的交互。
四、安全机制与行业标准
刷写升级的安全机制主要解决三个问题：谁可以刷、刷的内容是否可信、刷坏了怎么办。常见手段包括：
- 安全访问（Security Access）：通过 Seed/Key 挑战应答，防止未授权诊断仪执行擦写操作。
- 固件签名与校验：对固件镜像做 CRC32、SHA-256 或 RSA/ECC 签名验证，确保完整性与来源可信。
- 安全启动（Secure Boot）：RH850 可配合硬件安全模块（HSM）或 ICUM 实现启动链校验。
- 回滚与防降级：通过版本号与防回滚计数器，阻止刷入旧版本或恶意固件。
- 掉电保护：升级标志、双备份区、原子写入策略，保证异常中断后可恢复。
行业标准方面，UDS（ISO 14229）定义了诊断服务，ISO 15765 定义了 CAN 传输层，AUTOSAR 定义了 Bootloader 与 Flash 驱动接口，ISO 26262 则对功能安全提出要求。OTA 场景还会涉及《汽车软件升级通用要求》等法规。
| 机制 | 作用 | 典型实现 |
|---|---|---|
| 安全访问 | 防止未授权刷写 | UDS 0x27 Seed/Key |
| 完整性校验 | 检测数据错误 | CRC32 / SHA-256 |
| 签名验证 | 确认固件来源 | RSA-2048 / ECC |
| 安全启动 | 启动链可信 | HSM / ICUM |
| 回滚保护 | 防止降级攻击 | 版本计数器 |
五、常见误区与复盘
误区二：擦除与写入不按扇区对齐，导致 RH850 Flash 操作失败或数据异常。
误区三：忽略 P2 超时与流控参数，刷写大固件时出现丢帧或超时中断。
误区四：没有升级标志与备份区，断电后设备变砖。
复盘建议：在项目早期就明确 Flash 分区表、通信矩阵、安全等级和回滚策略；刷写流程必须经过“正常刷写、断电中断、错误固件、非法诊断仪”四类测试；所有关键状态迁移都要有日志或标志位可追溯。只有把原理、接口、流程、安全和标准串成一条链，RH850 Bootloader 的刷写升级才具备量产可靠性。