📚 课程目录第2章 AURIX安全软件测试的硬件与工具链准备

2. AURIX安全软件测试的硬件与工具链准备

AURIX TC3xx/TC4xx 的安全软件测试不是把程序烧进板子跑一遍那么简单。安全机制（SMU、Lockstep、ECC、MPU、时钟监控等）的验证高度依赖硬件平台、调试通道、Trace 采集能力以及电源与时钟的可控性。测试环境搭建的目标，是让"故障注入—安全响应—结果观测"这条链路可重复、可追溯、可版本化。本节围绕目标板、调试接口、Trace 工具、电源与时钟配置、环境搭建与版本管理五个方面展开。

一、目标板：TC3xx 与 TC4xx 的选型差异

TC3xx（如 TC375、TC397）与 TC4xx（如 TC4D7、TC4E7）在测试准备上的关键差异在于内核架构、安全机制粒度与调试资源。TC3xx 基于 TriCore 1.6.x/1.8，Lockstep 通常以 CPU 对为单位；TC4xx 引入更高性能内核与更细的安全分区，SMU 告警路由和故障注入寄存器布局也不同。选板时优先确认三点：

是否带完整调试口：TC3xx 常用 DAP（Debug Access Port）或 JTAG，TC4xx 以 DAP 为主，需确认 10-pin/20-pin 排针与目标板丝印一致。
是否引出 Trace 引脚：TC3xx 的 LQFP/BGA 封装中，Trace 引脚（TRCLK、TRDATA 等）常与 GPIO 复用，需确认板上有测试点或排针。
供电与复位可控：安全测试常需强制复位或断电重启，目标板应支持外部复位输入与独立供电切换。

教学示例中，若使用 TC375 Lite Kit 做入门验证，其板载 DAP 可直接通过 USB 连接；但若要做 Lockstep 故障注入，需确认板上有可访问的故障注入寄存器（如 FLASH 的 ECC 错误注入位），否则需外接最小系统板。

二、调试接口与 Trace 工具链

调试接口负责下载、单步、读写寄存器；Trace 工具负责在不打断 CPU 的前提下记录指令流、数据访问和时序。两者常被混为一谈，但安全测试中分工明确：调试接口用于配置故障注入和读取 SMU 状态，Trace 用于观测故障发生前后内核的真实行为。

典型工具链组合：

调试器：Infineon DAP miniWiggler 或 Lauterbach TRACE32（支持 TC3xx/TC4xx 的 OCDS 调试）。
Trace 探头：Lauterbach CombiProbe 或 Infineon 的 AURIX Trace 工具，采集 MCDS（Multi-Core Debug Solution）数据。
上位机：TRACE32 PowerView 或 Infineon 的 AURIX Development Studio，用于脚本化测试。

配置 Trace 时，关键参数包括采样时钟（通常与 CPU 时钟分频）、Trace 缓冲区大小、触发条件（如 SMU 告警触发、特定地址访问）。例如，设置触发条件为"SMU 告警状态寄存器 bit0 置位"，可捕获故障注入后第一条异常指令。若 Trace 缓冲区不足，可启用循环缓冲模式，只保留触发点前后各 2K 条记录。

三、电源与时钟配置

安全测试中，电源和时钟不是"接上就行"，而是需要可编程控制。原因在于：许多安全机制（如欠压监控、时钟监控）的验证需要主动制造异常条件。例如，验证 SMU 对 VDD 欠压的响应，需要电源能在毫秒级内从 1.3V 降到 1.1V 并保持，同时记录 SMU 告警时间戳。

推荐配置：

可编程电源：支持电压/电流回读，分辨率至少 1mV/1mA，通信接口（LAN/GPIB）可脚本控制。
外部时钟发生器：用于替代板载晶振，频率可调（如 20MHz ±5%），验证时钟监控窗口。
复位控制：通过调试器或外部继电器控制 PORST，实现上电复位、热复位、看门狗复位等场景。

教学示例参数：若验证 TC375 的时钟监控，可将外部时钟从 20MHz 逐步偏移到 18MHz，观察 SMU 是否在偏移超过 ±3% 时触发告警。记录从频率偏移到告警输出的延迟，判断是否满足安全手册中的响应时间要求。

四、测试环境搭建与版本管理

测试环境搭建的核心是"可复现"。建议按以下顺序建立：

硬件连接固化：将目标板、调试器、Trace 探头、电源、时钟源的连接方式拍照并标注，形成接线图。
工具链版本锁定：记录 TRACE32 固件版本、AURIX Development Studio 版本、编译器版本（如 Tasking V6.3r1）。
测试脚本入库：所有 TRACE32 脚本（.cmm）、Python 自动化脚本、配置文件纳入 Git 管理。
基线快照：每次测试前，用脚本读取目标板 ID、Flash 校验和、SMU 配置寄存器，存入测试报告。

版本管理不只是代码，还包括硬件配置。建议在 Git 仓库中建立 hardware/ 目录，存放接线图、电源配置、时钟配置；scripts/ 目录存放测试脚本；reports/ 目录存放每次测试的日志和 Trace 文件。每次测试提交时，用 commit message 记录目标板序列号、工具链版本和测试用例编号。

实用建议：在测试环境搭建完成后，先跑一次"空载基线"——不注入任何故障，只运行正常程序并采集 Trace。这份基线数据用于后续对比：当注入故障后，Trace 中出现的异常指令、SMU 告警时间、复位次数，都可以与基线对照，快速判断是安全机制正常响应还是测试环境本身引入的噪声。

常见问题：Trace 引脚与 GPIO 复用导致采集失败。TC3xx 部分封装中，Trace 引脚默认功能为 GPIO，需在启动代码中配置为 Trace 模式。若忘记配置，Trace 探头会采集到空数据或错误数据。排查方法：用调试器读取端口配置寄存器，确认 Trace 引脚已切换到 ALT 功能。

完成以上准备后，测试环境应达到的状态是：给定一个测试用例编号，任何人按接线图和脚本能复现相同的硬件连接、相同的工具链版本、相同的初始条件，并得到可对比的 Trace 和 SMU 日志。这是后续故障注入与安全机制验证的基础。