📚 课程目录第1章课程导入与工程环境搭建

1. 课程导入与工程环境搭建

RA与RX是瑞萨两条并行的MCU产品线：RA基于Arm Cortex-M内核，RX基于瑞萨自研RX内核。两者在寄存器组织、启动流程、调试接口和烧录协议上差异明显，但在自动化测试工程中，它们共享同一套工程化思路——用可版本管理的脚本、可复现的配置和可判读的日志，把"点按钮烧录、肉眼看串口"的手工操作，转化为可批量、可回归、可追溯的测试流水线。本章的目标不是立刻写出测试用例，而是先把"能稳定跑起来"的地基打好。

1.1 明确目标、范围与交付物

自动化测试工程的第一步是界定边界，否则很容易陷入"什么都想测、什么都测不深"的困境。建议在项目启动时用一份简短的测试范围说明锁定以下内容：

测试目标：例如验证RA6M5的Flash读写一致性、RX651的SCI串口回环吞吐、低功耗模式唤醒时间等，目标应可量化。
测试范围：明确覆盖哪些外设（GPIO、UART、SPI、I2C、ADC、Flash、时钟）、哪些芯片型号与封装、哪些工作电压与温度条件。
不在范围内：例如RF性能、EMC认证、量产老化测试，明确排除可避免后期争议。
交付物：测试工程源码（含构建脚本）、测试用例清单、测试报告模板、烧录与调试配置文件、环境搭建说明文档。

交付物中最容易被忽视的是"环境搭建说明文档"。它应记录工具版本号、安装路径、驱动版本、板卡跳线设置，使另一位工程师能在半天内复现出同样的工作区。这正是"可复现"的核心含义。

1.2 工具链安装与配置

RA/RX自动化测试通常需要四类工具协同工作，它们的分工与数据流向如下：

e² studio面向RA系列，基于Eclipse，内置FSP（Flexible Software Package）配置器。安装时选择"RA"系列支持包，并勾选GCC Arm Embedded编译器。安装完成后需在Window → Preferences → Renesas → RA中确认FSP版本与目标芯片一致。

CS+面向RX系列，是瑞萨自有的集成开发环境。安装时选择RX编译器（CC-RX），并安装对应的设备文件包。CS+的工程结构与e² studio不同，自动化构建需通过命令行csplus_console调用。

Renesas Flash Programmer (RFP)是独立的烧录工具，支持RA/RX的串口、USB、JTAG等方式。自动化测试中常用其命令行版本rfp-cli，通过脚本传入工程文件和芯片型号完成批量烧录。例如：

rfp-cli -device RA6M5 -tool E2LITE -if SWD -a -p "test_project.hex" -run

该命令表示：目标芯片RA6M5，使用E2 Lite调试器，SWD接口，自动擦除后烧录test_project.hex，烧录完成后复位运行。

J-Link / E2调试器：J-Link由SEGGER提供，支持RA/RX的SWD/JTAG调试，配合J-Link Commander可脚本化执行复位、读内存、写寄存器等操作。E2 Lite是瑞萨原厂调试器，与e² studio和CS+集成度更高。两者在自动化测试中可互为备份，但需注意驱动版本与固件版本的匹配。

串口工具：推荐使用支持脚本化的工具，如Python的pyserial或PuTTY配合plink。典型配置为115200波特率、8数据位、无校验、1停止位。在自动化脚本中，串口用于发送测试命令并捕获目标板返回的日志。

1.3 建立可复现的测试工作区

工作区目录结构建议如下，核心原则是"配置与代码分离、脚本与产物分离"：

ra_rx_auto_test/
├── config/
│   ├── devices.yaml        # 芯片型号、调试器、串口号
│   └── toolchain.yaml      # 工具路径与版本
├── projects/
│   ├── ra6m5_gpio_test/    # e² studio 工程
│   └── rx651_uart_test/    # CS+ 工程
├── scripts/
│   ├── build.py            # 调用命令行构建
│   ├── flash.py            # 调用 rfp-cli 烧录
│   └── run_test.py         # 串口交互与结果判定
├── reports/
│   └── template.html       # 测试报告模板
└── README.md               # 环境搭建说明

其中devices.yaml是复现的关键，它把"哪块板子接在哪个端口、用哪个调试器"这类易变信息集中管理：

targets:
  - name: ra6m5_board
    chip: RA6M5
    debugger: E2LITE
    interface: SWD
    serial_port: COM7
    baudrate: 115200
  - name: rx651_board
    chip: RX651
    debugger: JLINK
    interface: JTAG
    serial_port: COM9
    baudrate: 115200

这样，当换一台电脑或换一块板子时，只需修改YAML文件，脚本无需改动。测试脚本run_test.py读取该配置，依次执行"构建→烧录→串口交互→结果判定→生成报告"。

版本锁定建议：在toolchain.yaml中记录e² studio、CS+、RFP、J-Link驱动的精确版本号。例如FSP 4.0.0与FSP 3.5.0生成的代码可能不兼容，版本漂移是"昨天能跑今天报错"的常见原因。

1.4 首次连通性验证

环境搭好后，不要急于写复杂测试。先用一个最小工程验证整条链路：在e² studio中新建RA6M5工程，配置一个GPIO翻转和一路UART发送"HELLO\r\n"。编译后用rfp-cli烧录，再用串口工具观察是否收到"HELLO"。若收到，说明构建、烧录、串口三条链路均通；若未收到，按"先查供电与跳线、再查串口端口号、最后查波特率"的顺序排查。

这一步的判定标准很明确：串口在1秒内收到预期字符串，且目标板LED按预期闪烁。只有这个最小闭环跑通，后续的自动化测试才有可靠的基础。否则，任何测试失败都无法区分是"被测功能有问题"还是"环境本身有问题"。

常见坑：RA系列部分板卡的调试接口与串口共用引脚，跳线帽位置错误会导致烧录成功但串口无输出；RX系列CS+工程默认可能未使能SCI时钟，需在代码中显式配置。这些细节应记录在README中，避免重复踩坑。

完成本章后，你应拥有一个可复现的工作区、一套版本锁定的工具链、一份设备配置文件和一次成功的连通性验证记录。这是后续所有自动化测试章节的起点。