📚 课程目录第4章 AURIX启动与自检软件设计

4. AURIX启动与自检软件设计

AURIX TC3xx 的启动过程并不是“上电即运行应用”这么简单。它是一条由硬件复位逻辑、BootROM 固件、用户启动代码和自检软件共同构成的链式过程。功能安全软件架构要做的，是把上电自检（POST）、启动时序控制、安全启动链校验、BIST 与硬件自检的软件集成，以及量产阶段的启动可靠性验证，统一纳入可度量、可追溯的设计中。

一、上电自检与启动时序的分层

AURIX 上电后首先进入 BootROM 阶段。BootROM 会读取启动模式引脚（如 HWCFG 引脚组合），判断是从内部 Flash、外部存储器还是调试接口启动，并完成基础时钟与部分存储器的初始化。随后控制权交给用户启动代码（Startup Code），此时才进入功能安全软件可干预的区间。

从功能安全视角，启动时序应划分为三个层次：硬件可信根层（BootROM 与固化逻辑）、启动自检层（POST、BIST、时钟/电源/存储自检）、应用初始化层（OS 启动、任务调度、安全机制使能）。安全启动链的核心思想是：每一层在把控制权交给下一层之前，必须验证下一层镜像的完整性与真实性，验证失败则进入安全状态（如停留在安全模式、禁止输出、点亮故障指示）。

一个典型的启动时序参数示例如下（示例值，需按项目实际时钟配置调整）：复位释放后 BootROM 约在数百微秒内完成，用户启动代码在 1~2 ms 内完成时钟与 RAM 初始化，POST 自检在 10~50 ms 内完成，应用初始化在 50~100 ms 内完成。这些时间预算必须在设计阶段确定，并在量产验证中测量。

二、安全启动链的软件实现

安全启动链通常采用“逐级校验”的方式。以 AURIX 为例，可在用户启动代码中先计算应用镜像的 CRC32 或使用 HSMSHE 计算 SHA-256，再与存储在受保护区域（如 UCB 或专用签名区）中的期望值比对。若使用 HSM（Hardware Security Module），还可实现基于非对称签名的验证，由 HSM 完成公钥运算，主核只负责搬运与比对结果。

实现时需要注意三点：第一，校验范围必须覆盖所有可执行代码与关键常量，不能遗漏中断向量表；第二，校验算法本身要防止被绕过，例如校验函数应放在受保护段，且校验结果不能被应用层随意改写；第三，校验失败后的处理必须明确，通常进入安全状态并记录故障码到 NVM。

/* 示例：启动阶段 CRC32 校验片段（伪代码） */
uint32_t crc_calc = Crc32_Calculate((uint8_t*)APP_START, APP_SIZE);
uint32_t crc_exp  = *(uint32_t*)CRC_EXPECT_ADDR;

if (crc_calc != crc_exp) {
    Safety_EnterSafeState(FAULT_APP_CRC_MISMATCH);
    while (1) { /* 停留在安全状态 */ }
}
/* 校验通过，继续应用初始化 */

三、BIST 与硬件自检的软件集成

AURIX 提供多种内建自检机制，软件集成的关键是把它们安排在正确的启动阶段，并处理自检对系统状态的影响。

LBIST（Logic BIST）：对逻辑电路进行自检，通常在上电后、应用启动前执行。LBIST 会占用较长时间，且可能影响 RAM 内容，因此必须在 RAM 初始化之前或之后按顺序安排。
MBIST（Memory BIST）：对 SRAM、Flash 等存储器进行自检。MBIST 会破坏被测存储器内容，因此必须在加载应用数据之前完成，或对被测区域做保存与恢复。
时钟与电源监控自检：通过 SMU（Safety Management Unit）配置时钟监控、电压监控的报警路径，并在启动阶段主动触发一次测试报警，确认报警能正确到达 SMU 并产生预期响应。
锁步核自检：通过向锁步核注入差异或使用专用自检寄存器，验证锁步比较逻辑本身是否有效。

软件集成的难点在于顺序与依赖。例如 MBIST 必须在 RAM 初始化前完成，否则会破坏已初始化的数据；而 LBIST 可能需要在时钟稳定后执行。一个合理的顺序是：时钟初始化 → MBIST → LBIST → RAM 初始化 → POST 校验 → 应用初始化。每一步完成后应检查自检结果寄存器，失败则进入安全状态。

四、量产启动可靠性验证

量产阶段的启动可靠性验证不能只依赖实验室单板测试。需要覆盖温度、电压、老化、批次差异等条件。建议从以下维度设计验证：

冷启动与热启动：分别在 -40°C、25°C、125°C 下重复上电，记录启动时间分布与自检通过率。
电压拉偏：在标称电压 ±10% 范围内测试，观察 BootROM 与 PLL 锁定是否稳定。
反复复位：连续执行数千次复位，统计安全启动链校验失败次数，确认无偶发误报。
故障注入：人为篡改应用镜像的一个字节，确认安全启动链能检出并进入安全状态。

验证数据应形成可追溯的记录。例如，某量产项目在 125°C 下连续 5000 次冷启动，启动时间中位数为 42 ms，最大值为 58 ms，安全启动链校验失败 0 次；在注入 1 字节篡改后，100% 进入安全状态。这类数据是判断启动可靠性是否达标的直接依据。

启动时间预算应在设计早期确定，并在每次软件变更后重新测量。若 POST 或 BIST 导致启动时间超出整车要求，可考虑将部分自检拆分到运行阶段的后台自检（Runtime BIST），但必须评估对实时性和安全完整性的影响。

五、工程实践中的常见问题

实际项目中，启动与自检软件最容易出问题的地方往往不是算法本身，而是顺序与状态管理。例如：MBIST 在 RAM 初始化之后执行，导致初始化数据被破坏；LBIST 执行期间看门狗未正确喂狗，导致复位循环；安全启动链校验通过后，应用层又覆盖了校验结果变量，使后续无法追溯。这些问题都需要在集成阶段通过启动日志和故障码记录来定位。

建议在启动代码中保留一个启动状态字（Startup Status Word），按位记录每个自检阶段的完成情况与结果。该状态字在启动完成后写入 NVM，量产下线检测和售后诊断都可以读取，用于判断车辆是否曾发生过启动自检失败。这样，启动自检就不只是“通过/不通过”的二元判断，而是具备可追溯的工程数据。