4. AURIX启动代码与基础软件集成

AURIX TC3xx 从上电到应用软件运行，中间要穿过一条由硬件固化逻辑、用户启动代码和 MCAL 初始化共同构成的链路。这条链路里任何一环配置错误，都会表现为“程序下载成功但不运行”“运行几毫秒后复位”“看门狗反复触发”等典型量产问题。理解 BootROM、启动序列、时钟初始化、看门狗配置与 MCAL 启动代码之间的先后依赖，是集成工作的第一道门槛。

BootROM 与启动模式选择

AURIX 上电或复位后，最先执行的是芯片内部固化的 BootROM（Firmware）。它不依赖外部 Flash，负责最基本的硬件自检、启动模式判定和引导加载。BootROM 通过采样若干启动模式引脚（在 TC3xx 上主要是 HWCFG 引脚组合）决定从哪个介质启动：内部 Flash、外部串行 Flash、CAN 引导加载、或通过调试接口进入引导模式。量产 ECU 通常固定为“内部 Flash 启动”，但开发阶段会用到 CAN/ASC 引导加载来刷写或恢复变砖的板子。

BootROM 还会读取用户配置区（UCB，User Configuration Block）中的信息，包括 Flash 保护设置、启动校验使能、以及是否启用 BootROM 的密码保护。这里有一个容易踩的坑：如果 UCB 中误开启了 Flash 读保护或错误设置了启动校验，芯片可能拒绝从内部 Flash 启动，直接停在 BootROM 等待引导。因此量产前必须确认 UCB 的配置与最终交付状态一致，且保留可恢复的引导通道。

启动序列与向量表

BootROM 完成判定后，把控制权交给用户启动代码。AURIX 的启动入口由复位向量决定，TC3xx 中复位后从固定地址取第一条指令，随后跳转到用户启动代码。启动代码的第一件事通常是设置栈指针、初始化必要的 CPU 寄存器，然后跳转到 C 运行环境入口（如 __start 或启动库提供的入口）。

在 AUTOSAR 语境下，这段启动代码往往由 MCAL 的启动模块（如 Mcu 的启动部分）和编译器启动库共同承担。它需要完成：初始化数据段（把已初始化变量从 Flash 拷贝到 RAM）、清零 BSS 段、设置中断向量表基址、以及为后续 MCAL 初始化准备最小运行环境。向量表的位置和重映射必须与链接脚本、MCAL 配置保持一致，否则中断会跳到错误地址。

时钟初始化：一切外设的前提

AURIX 复位后默认运行在内部备份时钟（约 100 MHz 量级，具体取决于型号），而量产 ECU 通常需要更高的系统时钟（如 300 MHz）以及精确的外设时钟。时钟初始化由 Mcu 模块的 Mcu_Init 和 Mcu_InitClock 完成，核心动作包括：配置 PLL 的输入分频、反馈分频和输出分频，等待 PLL 锁定标志置位，然后切换系统时钟源到 PLL，最后通过 CCU（Clock Control Unit）把时钟分配到各外设。

这里的关键是“等待锁定”。PLL 配置寄存器写入后，必须轮询锁定状态位，确认稳定后才能切换时钟源。如果跳过这一步直接切源，CPU 可能取到未稳定的时钟，表现为随机跑飞。另一个细节是时钟监控：TC3xx 提供时钟监控和频率检测机制，若外部晶振失效，系统可自动切回备份时钟并触发报警。量产配置中应明确这些监控的响应策略，是复位还是降级运行。

看门狗配置：安全与可调试的平衡

AURIX 的看门狗（WDT）由 Wdg 模块管理，但底层涉及安全看门狗（Safety WDT）和 CPU 看门狗。配置要点有三个：超时周期、喂狗窗口、以及 ENDINIT 保护。超时周期必须大于最坏情况下两次喂狗之间的时间，否则会误复位；喂狗窗口（如果启用）要求喂狗不能太早也不能太晚，防止程序跑飞后恰好喂中。

ENDINIT 是 AURIX 特有的保护机制：对关键寄存器（包括看门狗、时钟、Flash 配置）的写操作，必须先清除 ENDINIT 位，写完后再置位。启动代码中如果忘记恢复 ENDINIT，后续任何对保护寄存器的写都会失败，且往往没有明显报错。调试阶段常见做法是先把看门狗超时设长或暂时关闭，但量产版本必须恢复为设计值，并在启动早期就完成 WDT 初始化，避免“裸奔”窗口过长。

MCAL 启动代码的集成顺序

MCAL 各模块的初始化不是随意排列的，而是有明确的依赖顺序。典型顺序是：Mcu（时钟与复位）→ Port/Dio（引脚）→ Wdg（看门狗）→ 通信与模拟驱动（Can、Adc、Pwm 等）→ EcuM 或 OS 启动。原因很直接：没有稳定时钟，外设寄存器写入无效；没有配置引脚，通信无法输出；没有看门狗服务，长初始化过程可能被复位。

集成时建议把启动过程分成两个阶段：第一阶段只做“最小可运行”初始化（时钟、看门狗、必要引脚），让系统先稳定下来；第二阶段再做完整外设初始化。这样即使某个外设初始化耗时较长，也不会因为看门狗超时而复位。同时，启动代码中应加入关键状态检查点，例如 PLL 锁定失败、时钟监控报警、看门狗复位标志等，通过读取复位状态寄存器判断上次复位原因，这对量产排障非常有价值。

常见集成问题与判断依据

如果程序下载后不运行，先确认 BootROM 是否真的跳到了用户 Flash：检查 HWCFG 引脚电平、UCB 启动配置、以及复位向量地址是否正确。如果运行几毫秒后复位，优先怀疑看门狗：读取复位状态寄存器中的 WDT 复位标志，并检查喂狗点是否在超时窗口内。如果通信外设无输出，检查时钟是否已切到 PLL、外设时钟是否使能、以及引脚是否被正确配置为外设功能。这些判断依据都来自启动链路上可观测的寄存器和引脚状态，而不是靠猜测。

把 BootROM、启动代码、时钟、看门狗和 MCAL 初始化看作一条有严格先后依赖的链路，集成时按依赖顺序推进、在每个环节留下可观测的状态检查点，就能把大部分“上电不跑”的问题挡在量产之前。