AUTOSAR Bootloader（引导程序）

AUTOSAR Bootloader（引导程序）

Bootloader（引导加载程序）是指在 ECM（ECU）中运行在主应用之前的一段固化程序，主要用来诊断刷写应用软件（Flash 编程），是量产、售后升级 ECU 固件的关键部件。AUTOSAR 环境下的 Bootloader 通常与诊断服务（Dcm）、存储栈（NvM/Fls）和UDS 编程会话紧密结合。

10.1 Bootloader 的作用

• 出厂烧录（EOL）：在产线上通过诊断刷写应用固件。
• 售后升级 / 召回：通过诊断仪（如 CANoe、OBD 工具）现场更新 ECU 应用软件。
• OTA 刷写：现代车辆通过远程 OTA 方式更新固件（需要安全、加密）。
• 看门狗 / 故障恢复：应用区损坏时能恢复到安全区域（bootloader 保底运行）。

核心原则：Bootloader 段足够小、可靠、稳定，不会因应用故障而无法启动。

10.2 ECU 存储分区（内存布局）

典型布局:

┌─────────────────────────────┐ 地址低位
│        Bootloader 区         │  固化、只读（充当"微小OS"）
├─────────────────────────────┤
│      Flash 驱动/设备科       │  刷写时用的 Flash 驱动（可放 RAM）
├─────────────────────────────┤
│       Application 区         │  实际功能固件（可更新）
├─────────────────────────────┤
│     配置/标定区（NVM）        │  标定、车辆配置、诊断数据
├─────────────────────────────┤
│   硬件保护区（Deriv，可选） │  安全访问/校验数据
└─────────────────────────────┘

• Bootloader 通常放在 Flash 起始地址（如 0x0800000x）+ 固定向量表。
• 应用有独立的向量表（VTOR）。
• Boot 判断是否需要刷写（比如收到诊断编程请求）以及应用校验是否通过。

10.3 刷写（Flash Programming）流程

刷写流程通常采用 UDS（ISO 14229，诊断） 驱动，典型步骤：

1. （会话）诊断会话：通过 0x10 03（Programming Session）进入编程会话。
2. （安全）安全访问：执行 0x27 解锁（Seed/Key）获得刷写权限。
3. （保护）清除：通过 0x31（例程控制）停止应用运行、检查电源。
4. （清）擦除：通过 0x31 例程「EraseMemory」擦除 Flash（或片内 FDC）。
5. 下载（Download）：0x34 RequestDownload 请求下载，得到内存地址与块大小。
6. 传输（TransferData）：0x36 分段发送固件数据（每段一个 TransferData 请求），传输后校验（每块 CRC）。
7. 结束（TransferExit）：0x37 结束下载。
8. 检验（Check）：通过 0x31 例程进行整体校验（CRC）。
9. 复位/重启：0x11 ECUReset 复位 ECU，运行新应用。

详细服务见第 4 篇《诊断服务》。

10.4 AUTOSAR 中 Bootloader 相关模块

• Dcm：接收/响应诊断服务（编程相关服务）。
• NvM：存储刷写相关的记录、临时校验、车辆状态。
• Fls/MemAcc：Flash 擦写驱动（Boot 刷写时对应用区 Flash 进行擦/写）。
• EcuM：管理复位/启动/运行状态切换。
• 安全相关（CSM/E2E）：做 OTA 时验证固件签名、加密（避免不安全固件）。

10.5 启动流程示例（从 Boot 到 App）

上电复位
   │
   ▼
[Bootloader] 初始化 MCU 最低环境
   │
   ├─ 检查"刷写请求标志"？
   │      ├── 是：进入编程（刷写），执行 UDS 刷写流程
   │      └── 否：继续
   ▼
校验 Application 有效性（CRC/签名校验）？
   ├── 有效：跳转到应用入口（Hardfic向量表设置偏移，跳转）
   └── 无效/缺失：停留在 Bootloader（进入下载等待）

跳转到应用的实现要点（嵌入式）

• 应用向量表偏移设置（如 SCB->VTOR = APP_BASE_ADDR）。
• 设置应用主栈（MSP）。
• 跳转到应用向量表 Reset 处理（((void(*)(void))*(uint32_t*)(APP_BASE_ADDR+4))()）。

10.6 常见问题与设计要点

1. 可靠性：Bootloader 必须首先保证自身不损坏；使用 A/B 分区（双 Bank）可避免刷写中断导致变砖。
2. 校验：刷写完成后必须校验（CRC/签名）再复位。
3. 掉电保护：刷写过程中断电，应能返回到可恢复状态（下次重新刷写）。
4. Flash 锁定：必要时在运行期间锁定 Flash 或使用安全机制防止恶意覆盖。
5. 协议与加密：OTA 通常采用 SecOC / CSM 加密 和 签名防止非法刷写。

小结

Bootloader 是 ECU 固件更新的基础设施：通过 UDS 编程会话、擦除、下载、校验等步骤实现安全刷写；启动时根据标志和校验决定是进入引导刷写还是跳转应用。它与 AUTOSAR 的 Dcm/NvM/Fls 紧密集成，是汽车软件更新（含 OTA）的核心。

这是本系列第 10 篇（Bootloader）。后续可继续探讨：AUTOSAR 安全（CSM/E2E）、OS、XCP 标定等。