📚 课程目录第4章 RH850开发环境搭建与工程创建

4. RH850开发环境搭建与工程创建

RH850 的 AUTOSAR 工程不是“装一个 IDE 就能跑”的单体软件，而是由编译器、调试器、AUTOSAR 配置工具链和 MCAL 驱动包共同拼装出来的。理解它们各自负责什么、在磁盘上如何落位、彼此通过哪些文件交互，是避免后续“配置生成了却编译不过”“调试器连不上目标板”这类问题的前提。本节先建立工具链的整体视图，再给出可执行的安装与配置路径，最后完成第一个可编译、可下载的 RH850 AUTOSAR 工程。

4.1 工具链的组成与职责边界

RH850 属于瑞萨 32 位车规 MCU 系列，常见内核为 G3M、G3KH 等。围绕它构建 AUTOSAR 工程，通常需要四类工具：

编译器与链接器：瑞萨官方的 CCRH（RH850 C Compiler）或 Green Hills、IAR 等第三方工具链。它把 C 源码、MCAL 驱动、生成的配置代码编译成 RH850 目标文件，并按链接脚本分配到 ROM/RAM 段。
调试器与仿真器：如瑞萨 E2/E2 Lite 仿真器配合 CS+ 或 e2 studio，或 Lauterbach TRACE32。负责通过 JTAG/CSI 接口连接目标芯片，实现下载、断点、变量观察和 Trace。
AUTOSAR 配置工具：DaVinci Configurator（Vector）或 EB tresos Studio（Elektrobit）。它们读取 ECU Extract、系统描述和 MCAL 模块描述，生成 ECU 配置代码（如 EcuM_Cfg.c、Com_Cfg.c、Mcu_Cfg.c 等）。
MCAL 与基础软件包：瑞萨提供的 RH850 MCAL 驱动、操作系统（如 ETAS RTA-OS 或 Vector MICROSAR OS）、通信栈等，是配置工具生成代码的“素材库”。

这四类工具的关系可以用下面的结构图表示。注意配置工具并不直接编译代码，它只产出配置源文件；编译器也不理解 AUTOSAR 语义，它只处理 C 代码。把这条边界记清楚，排障时就能快速定位问题出在哪一环。

4.2 安装顺序与关键配置项

安装顺序建议遵循“先底层、后上层”的原则，否则配置工具可能找不到 MCAL 模块描述文件。推荐顺序为：编译器 → 调试器驱动 → MCAL 包 → AUTOSAR 配置工具 → 集成开发环境（e2 studio 或 CS+）。

以 Windows 环境为例，几个容易出错的配置点如下：

编译器路径：CCRH 安装后需将 bin 目录加入系统 PATH，或在 IDE 中显式指定 CCRH_INSTALL 环境变量。验证方式是命令行执行 ccrh -v，能打印版本号即成功。
License 配置：DaVinci Configurator 和 EB tresos 都需要 License。DaVinci 通常使用 Vector License Client 绑定 MAC 地址；EB tresos 使用 license.dat 并设置 EB_TRESOS_LICENSE 环境变量。License 未生效时，工具能打开但无法生成代码。
MCAL 插件注册：EB tresos 需要把 RH850 MCAL 的 .epc 或插件目录注册到 plugins 路径下；DaVinci 则通过 DaVinciConfigurator.ini 中的 mcalPath 指向 MCAL 根目录。
调试器驱动：E2 Lite 需安装瑞萨的 USB 驱动，安装后在设备管理器中应出现 “Renesas E-Series USB Driver”。若显示未知设备，调试器无法连接。

建议在安装完成后，先用一个最简单的裸机 LED 工程验证“编译 + 下载 + 运行”这条链路是否通畅，再进入 AUTOSAR 工程创建。这样可以把工具链问题和 AUTOSAR 配置问题分开排查。

4.3 创建第一个 RH850 AUTOSAR 工程

下面以 EB tresos Studio + RH850 MCAL + CCRH 为例，给出一个最小可编译工程的创建过程。假设目标芯片为 RH850/F1KM，工程名为 Rh850AUTOSAR_Demo。

第一步：新建工程并选择目标。在 EB tresos 中执行 File → New → Project，选择 “AUTOSAR Project”，输入工程名，芯片选择 RH850/F1KM，工具链选择 CCRH。此时工具会生成工程骨架，包括 config、generate、src 三个目录。

第二步：导入 MCAL 模块。在工程上右键 Import → MCAL Modules，勾选本工程需要的最小模块集：Mcu、Port、Dio、EcuM、Os。导入后，工程树中会出现对应的 .xdm 配置文件。不要一次性导入全部模块，模块越多，配置依赖越复杂，首次搭建容易卡在依赖校验上。

第三步：配置时钟与端口。打开 Mcu.xdm，设置 PLL 倍频参数。例如外部晶振 16 MHz，目标系统时钟 80 MHz，则配置 PLL 倍频系数为 5、分频为 1，得到 80 MHz。打开 Port.xdm，把用于 LED 的引脚（例如 P0_0）配置为输出模式，初始电平为低。这两个配置是后续代码能“跑起来”的最小集合。

第四步：生成配置代码。点击工具栏的 “Generate” 按钮，工具会在 generate 目录下输出 Mcu_Cfg.c/h、Port_Cfg.c/h、EcuM_Cfg.c/h 等文件。生成成功时，控制台会打印 “Generation finished successfully”，并且每个 _Cfg.c 文件头部会带有生成时间戳。若报错，优先检查模块版本是否与 MCAL 包匹配。

第五步：编写启动代码并编译。在 src 目录下新建 main.c，内容如下：

#include "Mcu.h"
#include "Port.h"
#include "Dio.h"

int main(void)
{
    Mcu_Init(&Mcu_Config);
    Mcu_InitClock(McuClockSettingConfig_0);
    while (Mcu_GetPllStatus() != MCU_PLL_LOCKED) { }
    Mcu_DistributePllClock();

    Port_Init(&Port_Config);

    for (;;) {
        Dio_WriteChannel(DioConf_DioChannel_LED, STD_HIGH);
    }
    return 0;
}

把 generate 和 src 目录加入编译路径，链接脚本使用 MCAL 包中提供的 rh850_f1km.ld。执行编译，若输出 .elf 文件且无未定义符号错误，说明配置代码与手写代码已经正确衔接。

第六步：下载与验证。用 E2 Lite 连接目标板，在调试配置中选择生成的 .elf，点击下载。若程序停在 while (Mcu_GetPllStatus() != MCU_PLL_LOCKED) 处，说明 PLL 未锁定，应检查晶振是否起振、Mcu 配置中的晶振频率是否与实际硬件一致。若程序能越过该循环并运行到 Dio_WriteChannel，用万用表测量 P0_0 应为高电平，说明从配置到硬件输出的整条链路已经打通。

首次工程不要急于加入 Com、Can、NvM 等通信与存储模块。这些模块依赖中断、DMA 和更复杂的时钟配置，一旦底层时钟或中断向量配置有误，现象会表现为“下载成功但不运行”，排查成本很高。先用 Mcu + Port + Dio 验证最小闭环，再逐步叠加模块。

4.4 常见问题与判断依据

现象	可能原因	判断方法
Generate 按钮灰色不可点	License 未生效或工程未选中	查看工具底部 License 状态栏；确认工程节点被选中
编译报 “Mcu_Config undefined”	生成的 `_Cfg.c` 未加入编译	检查编译文件列表中是否包含 `generate` 目录下的源文件
调试器无法连接目标	USB 驱动异常或 JTAG 线序错误	设备管理器查看驱动状态；核对目标板 JTAG 引脚定义
程序下载后不运行	复位向量或链接脚本地址错误	查看 `.map` 文件中 `main` 与复位向量地址是否落在 ROM 区间

把上述流程走通一次之后，后续工程就可以复用同一套工具链配置和 MCAL 路径，只需要替换芯片型号和模块集合。真正需要反复调整的，往往是时钟树、端口复用和中断优先级这三类与具体硬件强相关的参数。