2. RH850微控制器基础
RH850 是瑞萨电子面向汽车电子与工业控制推出的 32 位 RISC 微控制器家族，其设计目标是在实时性、功能安全与低功耗之间取得平衡。对于 Bootloader 与刷写升级工程而言，理解 RH850 的架构、内核、存储映射和启动流程，是设计可靠升级方案的前提。本节从工程视角梳理这些基础知识，并给出与刷写直接相关的关键要点。
一、RH850 系列架构与内核特性
RH850 家族内部按应用场景分为多个子系列，例如面向车身控制的 RH850/F1x、面向动力与底盘的 RH850/P1x、面向仪表与网关的 RH850/D1x 等。它们共享同一套 32 位 RISC 内核架构，但在外设、存储容量、安全模块和封装上有所差异。内核层面最值得关注的是以下几点：
- 指令集与流水线：RH850 采用 32 位 RISC 指令集，具备多级流水线，支持单周期执行多数指令，中断响应延迟低，适合对实时性要求高的刷写控制逻辑。
- 寄存器组与中断：内核提供通用寄存器、程序计数器、状态寄存器以及多级中断控制器（INTC）。中断向量表可重定位，这对 Bootloader 与 App 之间的跳转和中断接管非常关键。
- 内存保护与安全：部分型号集成 MPU、CRC 校验单元、ECC 存储保护以及硬件安全模块（HSM），可用于校验刷写镜像的完整性和真实性。
- 低功耗与时钟：支持多种低功耗模式，刷写过程中需注意时钟切换和看门狗配置，避免升级中途复位。
二、存储映射与启动流程
RH850 采用统一的 32 位地址空间，典型映射包括：Code Flash（程序存储）、Data Flash（数据存储）、Local RAM、Global RAM、外设寄存器区以及选项字节区。不同子系列的具体地址边界不同，但结构相似。Bootloader 通常占据 Code Flash 的低地址区域，App 位于其后，两者之间通过固定偏移或向量表约定跳转入口。
启动流程大致如下：上电复位后，内核从复位向量处取指，首先执行启动代码（Startup Code），完成栈指针初始化、时钟配置、RAM 初始化以及 C 运行时环境准备。随后根据选项字节或启动模式判断进入 Bootloader 还是直接跳转 App。若进入 Bootloader，则等待刷写命令或超时后跳转 App。
典型启动顺序：
复位 → 取复位向量 → 初始化 SP/时钟/RAM
→ 读取选项字节与启动标志
→ 判断升级请求？
是 → 进入 Bootloader 刷写流程
否 → 校验 App 有效性 → 跳转 App 入口
这里有一个常见误区：很多开发者认为只要把 App 烧录到 Flash 就能直接运行，实际上 App 的向量表必须与 Bootloader 约定一致，且中断向量需要正确重定位。否则一旦 App 中发生中断，CPU 可能跳回 Bootloader 的向量表，导致行为异常。
三、开发工具链概览
RH850 的主流开发工具链包括瑞萨官方的 CS+ 与 e² studio，编译器通常使用 CCRH（瑞萨自有编译器）或 GCC for RH850。调试器方面，E1/E2 仿真器配合瑞萨的调试接口（如 JTAG、LPD）可完成下载、单步和 Flash 编程。对于 Bootloader 工程，还需要关注以下工具与文件：
| 工具/文件 | 用途 | 与刷写的关系 |
|---|---|---|
| CS+ / e² studio | 集成开发环境 | 编译 Bootloader 与 App，生成可烧录镜像 |
| CCRH / GCC | C 编译器 | 生成符合 RH850 指令集的机器码 |
| 链接脚本（.ld/.dr） | 定义存储布局 | 划分 Bootloader 区、App 区、向量表区 |
| Hex/Bin 转换工具 | 生成刷写镜像 | 产出可被 Bootloader 解析的升级文件 |
| E1/E2 仿真器 | 调试与烧录 | 用于开发阶段验证 Bootloader 跳转逻辑 |
四、案例与工程要点
假设一个车身控制器项目使用 RH850/F1x，Bootloader 位于 0x00000000 起始的 64KB 区域，App 从 0x00010000 开始。启动时 Bootloader 先检查 Data Flash 中的升级标志，若标志有效则通过 CAN 接收新镜像并写入 App 区，写入完成后校验 CRC，最后清除标志并跳转 App。这个过程中需要特别注意：
- 跳转前必须关闭所有中断，并重新设置栈指针到 App 的栈顶。
- App 的向量表需要复制到 RAM 或通过 MPU 重定位，确保中断正确响应。
- 刷写期间看门狗必须被喂狗或暂时关闭，否则会触发复位。
- 选项字节中的启动模式配置错误，可能导致芯片无法进入 Bootloader。
五、复盘与常见误区
从工程复盘角度看，RH850 Bootloader 开发中最容易出问题的环节往往不是刷写协议本身，而是对存储映射和启动流程的理解偏差。例如：误以为 App 可以直接使用绝对地址跳转而不需要重定位向量表；误以为 Data Flash 和 Code Flash 的擦写特性相同；误以为所有 RH850 子系列的启动流程完全一致。实际上，不同子系列在选项字节、启动模式和 Flash 控制器寄存器上存在差异，必须查阅对应型号的硬件手册。
因此，在进入具体刷写协议设计之前，建议先完成三件事：确认目标芯片的存储映射表、确认启动流程与向量表约定、确认工具链生成的镜像格式与链接脚本。这三项工作直接决定了后续 Bootloader 的可靠性和可维护性。