1. 课程导入与整车刷写全景

在整车电子电气架构中，ECU 的软件更新能力已经从“售后维修手段”演变为“整车全生命周期可运营能力”。RH850 作为瑞萨面向车身、网关、域控制器等场景的 32 位 MCU 系列，其 Bootloader 往往承担着“把新固件安全、可靠、可恢复地写入 Flash”的核心职责。本课程围绕 RH850 Bootloader 与整车刷写系统展开，目标不是只讲一个跳转函数，而是把 Bootloader 本体、通信链路、上位机刷写工具、整车诊断协议、刷写流程与安全机制 串成一条可落地的工程链路。

先建立整车视角。现代整车刷写通常由诊断入口发起：诊断仪或 OTA 云端下发刷写任务，经中央网关路由到目标 ECU 所在的 CAN/CAN FD 或以太网网段，目标 ECU 进入 Bootloader 后，通过 UDS 诊断服务（如 0x34 请求下载、0x36 传输数据、0x37 退出传输）接收固件数据并写入 Flash。RH850 在其中既是“被刷写对象”，也是“刷写协议的从节点”。理解这一点，才能明白为什么 Bootloader 的地址布局、Flash 驱动、看门狗处理、通信超时策略会直接影响整车刷写成功率。

从图中可以看到，刷写系统由四层组成：任务层（云端/诊断仪）、路由层（中央网关）、节点层（RH850 目标 ECU）以及 MCU 内部资源层（Bootloader 区、Application 区、共享外设）。这四层之间通过诊断报文和固件数据流耦合，任何一层配置不当都会导致刷写失败。例如网关未开放目标 ECU 的诊断路由，0x34 请求就无法到达；Bootloader 未正确初始化 CAN FD 波特率，0x36 数据传输就会超时；Flash 驱动未处理擦除对齐，写入就会返回否定响应。

本课程的学习路线按“先全景、再分区、后通信、再安全、最后联调”推进。第①阶段建立整车刷写全景，明确 RH850 在电子电气架构中的位置；第②阶段深入 RH850 Flash 架构，理解 Bootloader 与 Application 的分区边界、向量表重映射和跳转条件；第③阶段实现 UDS 刷写服务与 CAN FD 通信，把 0x34/0x36/0x37 服务真正跑通；第④阶段补齐 Flash 驱动、CRC 校验、看门狗喂狗和安全访问机制；第⑤阶段进行整车刷写联调，覆盖正常刷写、断电恢复、校验失败重试等场景。

为了让学习目标可衡量，建议在开始前先明确几个关键参数。以某车身域控制器为例，假设 RH850 的 Code Flash 为 2 MB，Bootloader 占用 64 KB，Application 占用 1.5 MB，剩余空间用于标定和备份区；CAN FD 仲裁段波特率 500 kbps，数据段 2 Mbps；UDS 刷写块大小设为 1024 字节，每块传输后由 Bootloader 返回 0x76 肯定响应。这些参数不是固定值，而是后续章节中需要根据实际项目调整的“可配置项”。

实战目标可以拆成三个可验证的结果：第一，能够独立搭建 RH850 Bootloader 工程，完成分区配置、Flash 驱动移植和跳转逻辑；第二，能够用诊断仪或自研上位机通过 CAN FD 完成一次完整固件升级，并观察 0x34/0x36/0x37 的报文交互；第三，能够模拟刷写中断、校验失败、看门狗复位等异常，验证 Bootloader 的恢复能力。达到这三个结果，就具备了整车刷写系统开发的基本工程能力。