第1章：ECU基础与升级原理

大家好，我是老张。在嵌入式这行摸爬滚打了十几年，从最早的8位单片机一路做到现在的多核异构处理器。今天咱们聊聊ECU远程升级这件事。说实话，OTA升级现在已经是汽车的标配功能了，但真正把它做稳、做安全，里面门道可不少。

这一章，我们先打好基础。把ECU的硬件长什么样、软件怎么分层、Flash怎么擦写、升级流程怎么走，这些核心概念理清楚。你想想看，如果连ECU的基本架构都不了解，后面谈升级策略、谈安全机制，那不就成了空中楼阁吗？

1.1 ECU的硬件架构

ECU，说白了就是汽车上的专用计算机。我习惯把它拆成三块来看：处理核心、存储系统、外设接口。

处理核心：主流方案是ARM Cortex-M系列（比如M4、M7）或者RISC-V内核。现在高端域控会用Cortex-A系列跑Linux。我个人建议，选型时别光看主频，实时性和中断响应往往更重要。

存储系统：这是升级的关键。一般包含：

• Flash：存放代码和常量数据。掉电不丢失。
• RAM：运行时数据、堆栈。掉电就丢。
• EEPROM：存标定参数、故障码。可以字节擦写。

我在项目中遇到过一个问题：某款芯片的Flash擦写寿命只有1万次，测试阶段频繁刷写，结果还没量产Flash就挂了。所以，选型时一定要看Flash的 endurance（耐久性）和 retention（数据保持能力）。

外设接口：CAN、LIN、FlexRay、以太网。OTA升级的数据通道，早期多用CAN，现在主流是车载以太网（100BASE-T1或1000BASE-T1）。带宽大，传输快，升级体验好。

1.2 ECU的软件架构：Bootloader + App

ECU的软件，我习惯把它分成两个世界：Bootloader 和 Application（App）。它们共享同一个Flash空间，但职责完全不同。

Bootloader：这是ECU上电后第一个跑的程序。它的任务很简单：

• 检查App是否有效（CRC校验）
• 如果App有效，跳转过去执行
• 如果App无效或收到升级指令，进入升级模式

嗯，这里要注意：Bootloader本身是不能被升级的（或者需要特殊保护机制）。否则一旦升级失败，ECU就变砖了。

Application（App）：这是ECU真正干活的部分。控制发动机、管理电池、处理ADAS数据，都在这里。App可以被OTA升级覆盖。

我见过一个典型的Flash分区布局：

分区	起始地址	大小	内容
Bootloader	0x08000000	64KB	启动代码、升级协议栈
App Slot A	0x08010000	512KB	当前运行的App
App Slot B	0x08090000	512KB	备份或待升级的App
参数区	0x08110000	64KB	标定参数、升级状态标志

这种双分区（A/B分区）设计，是OTA升级的黄金方案。升级时写B区，写完后切到B区启动。如果B区启动失败，自动回滚到A区。我曾经用这个方案帮客户解决了一个大问题——升级过程中意外断电，ECU照样能正常启动。

1.3 Flash驱动原理

Flash驱动，说白了就是操作Flash的底层代码。它负责擦除、写入、读取三个基本操作。

擦除：Flash只能从1写成0，不能从0写成1。所以写入前必须先擦除。擦除的最小单位是扇区（Sector），大小从4KB到128KB不等。擦除操作很慢，一个扇区可能要几十毫秒。

写入：写入的最小单位是页（Page）或字（Word）。写入前要确保目标地址已经被擦除。写入速度比擦除快，但也要几微秒到几毫秒。

读取：Flash可以直接像RAM一样读取，但速度慢一些。一般CPU会通过预取缓存来加速。

我写一个简单的Flash写入函数示例：

// 伪代码：Flash页写入
bool Flash_WritePage(uint32_t addr, uint8_t *data, uint32_t len) {
    // 1. 检查地址对齐
    if (addr % FLASH_PAGE_SIZE != 0) return false;
    
    // 2. 解锁Flash控制器
    FLASH->KEYR = 0x45670123;
    FLASH->KEYR = 0xCDEF89AB;
    
    // 3. 等待上次操作完成
    while (FLASH->SR & FLASH_SR_BSY);
    
    // 4. 逐字写入
    for (uint32_t i = 0; i < len; i += 4) {
        *(volatile uint32_t *)(addr + i) = *(uint32_t *)(data + i);
        while (FLASH->SR & FLASH_SR_BSY);
    }
    
    // 5. 锁定Flash控制器
    FLASH->CR |= FLASH_CR_LOCK;
    
    return true;
}

1.4 升级流程概览

好了，前面把硬件、软件、Flash驱动都讲了一遍。现在我们把它们串起来，看看一次完整的OTA升级是怎么走的。

我习惯把升级流程分成五个阶段：

1. 下载阶段：ECU通过以太网或CAN接收升级包。数据分块传输，每块带CRC校验。接收完一块，回复ACK。
2. 校验阶段：所有数据接收完成后，对整个升级包做完整性校验（比如SHA256）。确保数据在传输过程中没有被篡改。
3. 备份阶段：如果是单分区方案，需要把当前App备份到外部存储或另一个分区。双分区方案则不需要这一步。
4. 写入阶段：调用Flash驱动，逐扇区擦除、逐页写入。写入过程中，绝对不能断电。我建议在写入前把看门狗喂饱，防止写入时间过长导致复位。
5. 激活阶段：写入完成后，设置启动标志。然后复位ECU。Bootloader检测到新App有效，跳转执行。如果启动失败，回滚到旧版本。

这里有一个关键点：升级包的大小。一个App可能有几百KB甚至几MB。通过CAN传输，速度只有500kbps，传完可能要几分钟。而以太网就快得多，几秒钟搞定。所以，升级通道的选择直接影响用户体验。

下一章，我们深入讲讲升级包的制作与差分算法。为什么一个几十MB的App，差分后只有几MB？这里面用了什么黑科技？到时候见分晓。