1. 课程导入
在汽车电子控制器（ECU）开发中，软件刷写升级是贯穿研发、产线、售后全生命周期的关键能力。RH850 作为瑞萨面向车身、底盘、动力域的主流 32 位 MCU 系列，其 Bootloader 设计既要满足 UDS（ISO 14229）诊断刷写规范，又要兼顾 Flash 驱动、安全校验、掉电保护与产线节拍。本课程以“能设计、能实现、能调试、能交付”为目标，带你从零构建一套可量产的 RH850 Bootloader 与刷写升级工程。
一、学习目标：从“会写代码”到“能交付刷写系统”
本课程不是单纯讲解某一段 Flash 驱动代码，而是围绕一个完整的刷写升级系统展开。学完后，你应当具备以下能力：
- 架构能力：能划分 Bootloader、App、NVM、诊断栈的边界，明确谁负责跳转、谁负责校验、谁负责回滚。
- 驱动能力：能基于 RH850 的 FACI/Flash 库完成擦除、写入、校验，并处理 ROP、时钟、看门狗等约束。
- 协议能力：能实现 UDS 的 0x34/0x36/0x37 服务，理解 S-record、HEX、BIN 与刷写块的关系。
- 工程能力：能设计双区/单区升级方案，处理断电续传、版本管理、签名校验与产线烧录。
- 调试能力：能定位“跳转失败、擦写超时、校验不过、刷写后不启动”等典型问题。
一句话目标：让你能独立交付一套“可刷、可验、可回滚、可量产”的 RH850 Bootloader 工程，而不是停留在能编译通过的 Demo。
二、核心概念：先建立正确的“刷写世界观”
在动手之前，必须厘清几个容易混淆的概念。它们决定了后续架构选型和代码组织方式。
| 概念 | 含义 | 在本课程中的关注点 |
|---|---|---|
| Bootloader | 上电后最先运行、负责判断是否刷写并跳转 App 的引导程序 | 启动流程、跳转条件、Flash 驱动、通信接口 |
| App（Application） | 实际业务功能固件，通常位于 Bootloader 之后的 Flash 区域 | 向量表偏移、链接脚本、版本信息、有效性标志 |
| UDS 刷写服务 | ISO 14229 定义的诊断服务，如 0x34 请求下载、0x36 传输数据、0x37 退出传输 | 会话控制、安全访问、块序号、超时与重传 |
| Flash 驱动 | 对 RH850 片内 Flash 进行擦除、编程、校验的底层代码 | FACI 命令、代码闪存/数据闪存、编程单位、等待周期 |
| 刷写镜像 | 待写入的固件数据，常见格式为 BIN、HEX、S19 | 地址映射、校验和、签名、分块传输 |
| 回滚与双区 | 升级失败时恢复到旧版本，或通过 A/B 区切换保证可用性 | 区切换标志、备份区、掉电保护、版本仲裁 |
其中最容易出错的是“地址空间”和“向量表”。RH850 上电后从固定地址取复位向量，Bootloader 必须把 App 的向量表重定位到正确位置，否则跳转后中断会跑飞。另一个高频误区是把“刷写成功”等同于“程序可运行”，实际上还需要校验、跳转、看门狗和时钟的配合。
三、整体知识框架：一张图看清学习路径
下图给出本课程的知识拓扑：从启动与存储基础出发，经过 Flash 驱动、通信协议、刷写状态机，最终落到双区升级与量产交付。它也是后续 30 章内容的主线。
四、方法流程：一个可落地的刷写升级主线
无论最终选择单区还是双区，刷写升级的工程主线都可以抽象为以下步骤。建议在项目初期就把这条主线写成状态机，而不是边写边补。
- 上电与初始化：关闭看门狗或延长超时，配置时钟，初始化通信接口，读取升级标志。
- 进入刷写模式判断：根据诊断请求、GPIO 电平、NVM 标志决定停留在 Boot 还是跳转 App。
- 安全访问：通过 0x27 服务完成种子密钥认证，防止未授权刷写。
- 请求下载（0x34）：协商地址、数据长度、块大小，准备接收镜像。
- 传输数据（0x36）：按块接收并写入 Flash，维护块序号，处理超时与重传。
- 退出传输（0x37）：结束下载，执行 CRC 或签名校验。
- 激活与跳转：写入有效标志，复位或直接跳转到 App 向量表。
- 失败回滚：若校验失败或跳转异常，恢复旧版本并记录故障码。
工程建议：把“刷写状态机”和“Flash 驱动”解耦。状态机只关心“收到什么、下一步做什么”，驱动只关心“擦哪里、写什么、校验结果”。这样调试时能快速定位是协议问题还是驱动问题。
五、案例与场景：为什么“能刷进去”不等于“能跑起来”
某车身控制器项目使用 RH850，Bootloader 能正常接收 UDS 数据并完成 Flash 写入，但刷写后 ECU 不启动。排查发现三个问题叠加：
- App 的链接脚本仍按默认 0x00000000 起始，未把向量表偏移到 Bootloader 之后的区域；
- 跳转前没有关闭看门狗，App 初始化时间较长导致复位；
- Flash 写入后只做了累加和校验，未做 CRC，某个块写入错误未被发现。
修正后，刷写流程稳定通过。这个案例说明：Bootloader 的难点不在“写 Flash”，而在启动、跳转、校验、看门狗、时钟这些系统级配合。后续章节会逐一拆解这些坑。
六、常见误区与复盘清单
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 把 Bootloader 和 App 编译进同一个工程却不分区 | 地址冲突，跳转后中断异常 | 明确分区，独立链接脚本，固定向量表偏移 |
| 刷写过程中不处理掉电 | App 区半写，设备变砖 | 双区备份 + 有效标志 + 上电回滚 |
| 只校验长度不校验内容 | 错误数据被激活，运行异常 | CRC32 或签名校验，校验通过才写有效标志 |
| 忽略看门狗和时钟初始化 | 刷写中途复位，跳转失败 | 刷写期间喂狗或延长超时，跳转前恢复时钟 |
| 没有版本管理和日志 | 售后无法追溯，产线无法统计 | 记录版本号、刷写次数、失败码，输出日志 |
提醒：刷写升级是“安全相关”功能，任何一次失败都可能导致车辆无法启动。请把回滚、校验、掉电保护当作必选项，而不是可选项。
七、实战路线图与代码准备
本课程后续将按“环境搭建 → Flash 驱动 → UDS 刷写 → 状态机 → 双区回滚 → 产线交付”推进。开始前，建议准备好以下工具链与素材：
# 建议的工程目录结构
rh850_boot/
├── bootloader/
│ ├── startup/ # 启动代码、向量表
│ ├── flash_driver/ # FACI 擦写校验
│ ├── uds/ # 0x34/0x36/0x37 服务
│ ├── state_machine/ # 刷写状态机
│ └── nvm/ # 升级标志、版本信息
├── application/
│ ├── app_main.c
│ └── linker_app.ld
├── tools/
│ ├── can_flash_tool.py # 上位机刷写脚本
│ └── crc32.py # 镜像校验工具
└── docs/
└── flash_layout.md # Flash 分区表当你完成本课程后，回头看这张知识框架图，应当能清楚说出每个节点对应的代码文件、关键寄存器和调试手段。这就是从“知道”到“做到”的分界线。