📚 课程目录第4章 S32G 启动流程与系统初始化

4. S32G 启动流程与系统初始化

S32G 的启动过程并不是“上电后直接跑应用”，而是一条由硬件固化逻辑牵引、逐级交接控制权的链。理解这条链，才能解释为什么某些通信外设（如 CAN、以太网、LIN、FlexRay）在应用代码尚未执行时就已经具备基本收发能力，也能解释为什么时钟或引脚配置错误会导致“程序能跑但通信不通”。本节围绕 BootROM、IVT、HSE 固件加载、多核启动以及时钟与引脚初始化五个关键环节展开，并重点说明它们对通信外设的直接影响。

一、BootROM：上电后的第一段代码

S32G 上电复位后，CPU 首先执行的是芯片内部固化的 BootROM。BootROM 不依赖外部存储，它负责最基础的硬件自检、启动模式判定以及后续镜像的加载。S32G 的启动模式由复位时的启动引脚（BOOT_CFG 等）采样决定，常见模式包括从 QSPI Flash、SD/eMMC、串行下载（UART/CAN 等）启动。BootROM 会读取这些引脚状态，选择对应的外部存储器接口，并尝试从固定偏移处读取启动头。

对通信外设而言，BootROM 阶段通常不会主动初始化 CAN 或以太网控制器，但它会初始化用于启动的接口（如 QSPI、SDHC、UART）。如果选择串行下载模式，BootROM 会通过 UART 或 CAN 接收主机发送的镜像，此时 CAN 的波特率、引脚复用由 BootROM 内部默认配置决定，开发者无法在应用层修改。因此，若使用 CAN 下载，必须确保硬件引脚与 BootROM 默认复用一致，否则连握手都无法完成。

二、IVT：镜像的“入口说明书”

BootROM 从外部存储器读取的第一个结构是 IVT（Image Vector Table）。IVT 通常位于镜像起始偏移处，包含自检信息、镜像入口地址、各段加载地址、HSE 固件入口、以及可选的启动配置。BootROM 解析 IVT 后，才知道把哪些数据搬到内部 SRAM 或 DDR，以及跳转到哪个地址执行。

IVT 中的 boot_data 字段会指定镜像长度和加载地址，entry 字段指向用户代码入口。若使用 HSE 安全启动，IVT 还会包含 HSE 固件的位置和认证信息。一个典型的 IVT 结构在代码中表现为：

typedef struct {
    uint32_t header;
    uint32_t reserved;
    uint32_t self_test;
    uint32_t boot_data;
    uint32_t entry;
    uint32_t hse_fw;
    uint32_t reserved2;
} ivt_t;

IVT 本身不直接配置通信外设，但它决定了 HSE 固件和用户代码的加载顺序。如果 IVT 中 HSE 固件地址错误，BootROM 会在加载阶段失败，系统可能停在串行下载模式或反复复位，此时所有通信外设都不可用。因此，IVT 的正确性是通信功能可用的前提。

三、HSE 固件加载：安全与通信的桥梁

S32G 内置 HSE（Hardware Security Engine）子系统，负责安全启动、密钥管理和加解密。HSE 固件通常由 NXP 提供，通过 IVT 指定地址加载到 HSE 专用 RAM 中。BootROM 在跳转到用户代码前，会先启动 HSE 固件并完成基本初始化。

HSE 固件加载对通信外设的影响体现在两方面：一是安全启动模式下，用户代码必须经过 HSE 验证后才能执行，若验证失败，系统不会进入应用，通信自然无法建立；二是 HSE 可提供安全通信服务，例如对 CAN 报文进行 MAC 校验、对以太网帧进行加密。若应用需要使用这些功能，必须在 HSE 固件加载完成后，通过 HSE 接口（如 MU 消息单元）与 HSE 交互，获取密钥句柄或验证结果。

HSE 固件加载失败时，S32G 通常会通过复位或进入安全停止状态来阻止未授权代码运行。调试时若发现系统反复复位，应优先检查 IVT 中 HSE 固件地址和认证配置，而不是先怀疑通信驱动。

四、多核启动：谁先跑，谁配置外设

S32G 包含多个 Cortex-A53 和 Cortex-M7 核心。BootROM 完成镜像加载后，通常由主核（如 A53 Core0 或 M7 Core0）首先执行用户代码，其他核心处于等待状态。多核启动的关键是“核间同步”：主核负责初始化时钟、引脚、DDR 和通信外设，然后通过核间中断或共享内存释放从核。

对通信外设的影响在于：如果从核在通信外设初始化完成前就访问 CAN 或以太网寄存器，可能读到未就绪状态或触发总线错误。因此，合理的做法是主核完成外设初始化后，再通过 MC_ME 或 MU 通知从核启动。例如，主核在初始化完 CAN0 后，设置共享内存标志 can0_ready = 1，从核轮询到该标志后再进行报文收发。

五、时钟与引脚初始化：通信外设的“物理前提”

时钟和引脚是通信外设工作的物理前提。S32G 的时钟树由 MC_CGM、PLL 和 FXOSC 等模块组成，通信外设（CAN、以太网、LIN、FlexRay）通常挂载在 AIPS 或 PERIPH 总线上，需要先使能对应时钟门控，再配置分频系数。例如，CAN 模块的协议时钟通常来自 CAN_CLK，若该时钟未使能，CAN 寄存器写入无效，发送请求也不会产生总线波形。

引脚初始化则通过 SIUL2 模块完成，包括复用功能选择、方向、上下拉和驱动能力。以 CAN0 为例，需要将对应引脚复用为 CAN0_TX 和 CAN0_RX，并配置为推挽输出和上拉输入。若引脚复用错误，CAN 控制器内部状态正常，但总线上无波形，示波器测量 TX 引脚无变化。以太网 RGMII 接口还需要配置 TX_CLK、RX_CLK 等时钟引脚，并确保 MDIO 引脚可用，否则 PHY 无法识别。

从图中可以看出，BootROM 和 IVT 决定“代码从哪里来”，HSE 决定“代码是否可信”，多核启动决定“谁先配置外设”，而时钟与引脚初始化决定“外设能否真正工作”。这五个环节中任何一个出错，都会在通信层面表现为“无波形、无链路、无应答”。因此，调试通信问题时，应按照启动链的顺序逐级排查：先确认 BootROM 启动模式正确，再确认 IVT 和 HSE 固件加载成功，然后确认主核已完成时钟和引脚初始化，最后才检查通信协议配置。

六、实操检查要点

在实际项目中，建议按以下顺序检查启动与初始化对通信外设的影响：

确认 BOOT_CFG 引脚电平与目标启动介质一致，避免 BootROM 进入错误模式。
用调试器读取 IVT 的 entry 和 hse_fw 字段，确认地址与链接脚本一致。
检查 HSE 固件是否加载成功，可通过 HSE 状态寄存器或 MU 消息确认。
确认主核在释放从核前已完成 CAN、以太网等外设的时钟使能和引脚复用。
用示波器测量通信引脚，区分“控制器未初始化”和“引脚未复用”两类问题。

例如，某项目使用 S32G274A，CAN0 配置为 500 kbps，但总线上无波形。排查发现 CAN_CLK 未使能，导致 CAN 控制器寄存器写入无效。使能时钟后，TX 引脚出现波形，但总线仍无应答，进一步检查发现 SIUL2 中 CAN0_TX 引脚复用为 GPIO 而非 CAN 功能。修正复用配置后，CAN 通信恢复正常。这个案例说明，启动链中的时钟和引脚初始化虽然位于应用代码之前，但它们的正确性直接决定通信外设能否工作。

在多核系统中，从核不应在通信外设初始化完成前访问外设寄存器。建议使用共享内存标志或核间中断进行同步，避免因访问未就绪外设导致总线错误或系统异常。

总结来说，S32G 的启动流程是一条从 BootROM 到 IVT、HSE、多核、时钟与引脚的完整链。通信外设的可用性不是应用代码单独决定的，而是这条链上每一级正确交接的结果。掌握每一级的作用和排查方法，才能在通信调试中快速定位问题根源。