2. AURIX微控制器基础

要理解AURIX上的Bootloader与刷写升级，不能只盯着通信协议和上位机工具，必须先回到芯片本身：TriCore内核如何取指、内存空间如何划分、上电后CPU从哪里开始执行、复位时哪些外设和寄存器会被清零。这些底层事实决定了Bootloader能放在哪里、能改哪些Flash、跳转前必须准备什么，以及为什么某些刷写失败其实是硬件依赖没有满足。

一、TriCore架构：三核一体的执行模型

TriCore是英飞凌AURIX系列的核心，它不是单纯的RISC CPU，而是把微控制器、DSP和实时内核三种能力集成在一个指令流水线中。对Bootloader而言，最需要关注的是它的地址空间、中断向量和上下文切换机制。

• 统一地址空间：TriCore采用32位线性地址，代码、数据、外设寄存器都映射在同一地址空间中，Bootloader可以直接用指针访问Flash、RAM和寄存器。
• 多级流水线：取指、译码、执行、写回并行，跳转指令会带来流水线冲刷，因此从Bootloader跳转到应用程序时必须使用正确的跳转序列。
• 上下文与中断：中断向量表通常位于PFlash起始区域，Bootloader若占用该区域，必须保证向量表不被应用程序覆盖，或显式重定位。
• 多核结构：AURIX通常包含多个TriCore核（如CPU0/CPU1/CPU2），上电后主核先运行，从核处于等待状态，Bootloader需决定何时释放从核。

二、内存映射：Bootloader的“地盘”划分

AURIX的地址空间大致分为PFlash（程序Flash）、DFlash（数据Flash）、RAM、外设寄存器和启动ROM。Bootloader工程的第一步，就是确定自己占哪一段、应用程序占哪一段、升级缓存放在哪里。

一个常见的分区策略是：Bootloader固定在PFlash起始段，应用程序从某个扇区边界开始，升级标志放在DFlash中。这样即使应用程序刷写失败，Bootloader仍然完整，可以重新进入升级模式。

三、启动流程与复位行为

AURIX上电或复位后，CPU从启动ROM开始执行，读取启动模式配置（如启动模式头、用户配置块），然后跳转到PFlash中的用户代码入口。Bootloader正是利用这一流程，在用户代码入口处“截获”控制权。

上电/复位
  → 启动ROM读取启动配置
  → 检查启动模式（内部Flash / 外部 / 引导加载）
  → 跳转到PFlash入口地址
  → Bootloader入口
      → 判断升级标志
      → 若需升级：进入刷写模式
      → 若无需升级：校验App并跳转
  → 应用程序入口

复位行为中有几个关键点直接影响Bootloader：

• 复位源多样：上电复位、看门狗复位、软件复位、外部复位引脚，Bootloader可通过复位状态寄存器区分来源，决定是否进入升级模式。
• RAM不保持：普通复位后RAM内容不确定，不能用RAM变量作为“下次进入升级”的持久标志。
• 外设复位：CAN、Flash控制器等复位后回到默认状态，Bootloader必须重新初始化时钟、CAN波特率和Flash等待周期。
• 看门狗：若看门狗在复位后默认开启，Bootloader必须在超时前完成喂狗或关闭，否则会反复复位。

四、Bootloader的硬件依赖与实操要点

Bootloader不是纯软件，它依赖一组硬件条件才能可靠工作。下面这张图展示了从复位到跳转App的关键信号链与依赖关系。

结合上图，Bootloader在跳转到应用程序之前，通常需要完成以下动作：

1. 关闭或重载看门狗，避免跳转后立即复位。
2. 将使用过的CAN、串口、定时器等外设复位到默认状态。
3. 设置应用程序的栈指针和入口地址，通常从App向量表读取。
4. 关闭全局中断，跳转后再由App重新初始化中断。
5. 校验App的合法性和完整性，例如检查入口地址、CRC或签名。

五、案例与复盘：一次跳转失败的分析

某项目在AURIX TC3xx上实现CAN Bootloader，刷写完成后跳转App，发现App运行几毫秒后系统复位。排查发现：Bootloader初始化CAN时开启了CAN中断，跳转前没有关闭；App重新初始化CAN时，旧中断向量仍指向Bootloader的中断服务程序，导致取指异常并触发看门狗复位。修正方法是在跳转前执行IfxCpu_disableInterrupts()并清除所有挂起中断标志，同时复位CAN模块。

这个案例说明：Bootloader的硬件依赖不仅是“能读写Flash”，还包括中断、看门狗、外设状态和时钟配置的完整交接。只有把复位行为、内存映射和启动流程都纳入设计，Bootloader才能在真实车上环境中稳定可靠地完成刷写升级。