📚 课程目录第3章刷写流程详解

Bootloader开发与ECU刷写调试 - 第3节

刷写流程详解：预编程、主编程、后编程三个阶段

刷写ECU，说白了就是给汽车的大脑做一次“软件升级手术”。这个手术不能乱来，得按流程走。我做了这么多年Bootloader，见过太多因为跳步骤导致ECU变砖的案例。今天咱们就把这个流程拆开揉碎了讲清楚。

整个刷写过程，业内标准做法是分成三个阶段：预编程、主编程、后编程。每个阶段都有它存在的道理，少一个都不行。

1. 预编程阶段：手术前的准备

预编程，我习惯叫它“清场阶段”。这个阶段的目标就一个：让ECU进入一个安全、可刷写的状态。

为什么要做这个？你想想看，ECU在车上不是孤立的，它连着CAN总线，跟其他ECU聊着天，还控制着执行器。你要是直接给它刷程序，万一它正在控制刹车或者油门，那不就出大事了？

预编程的核心任务：

关闭DTC（诊断故障码）存储——防止刷写过程中误报故障
停止通信报文——让ECU从网络里“隐身”
禁用执行器控制——确保不会误动作
保持唤醒状态——防止ECU在刷写中休眠

我记得有一次在台架上测试，忘了关DTC存储，结果刷到一半ECU报了个“电压过低”的故障码，直接中断了刷写流程。从那以后，我每次都会在预编程阶段多检查一遍这些条件。

2. 主编程阶段：真正的数据传输

主编程就是干正事的时候了。这个阶段负责把新的应用程序（APP）数据通过CAN、CAN FD或者以太网，一块一块地写进ECU的Flash里。

主编程内部又细分为几个子步骤，我一般用状态机来管理：

步骤	动作	说明
1. 请求下载	0x34服务	告诉ECU：我要开始写数据了，准备接收
2. 传输数据	0x36服务	把数据分包发送，每包通常4KB或8KB
3. 请求退出	0x37服务	通知ECU：数据发完了，你校验一下
4. 校验完整性	CRC或SHA256	确保数据没被篡改或传输出错

这里有个坑，我必须要说。传输数据时，每发一包都要等ECU的应答。如果应答超时，你得决定是重发还是跳过。我曾经遇到过CAN总线干扰，连续丢包3次，如果没做重试机制，那次刷写就废了。

注意：主编程期间绝对不能断电！一旦掉电，Flash里的数据可能只写了一半，ECU就彻底变砖了。我建议在硬件设计上加上掉电检测，软件里做断点续传。

3. 后编程阶段：善后与恢复

数据写完了，不代表完事了。后编程阶段要把ECU恢复到正常工作状态。说白了，就是把预编程阶段改回去的东西，再改回来。

后编程要做的事：

重新启用DTC存储
恢复通信报文
重新启用执行器控制
执行一次“复位”让ECU用新程序启动

嗯，这里有个细节。复位之后，ECU会从Bootloader跳转到新应用程序。如果新程序有问题，ECU可能起不来。所以很多Bootloader会做“回滚”机制——如果新程序启动失败，自动切回旧版本。

刷写状态机：流程的灵魂

上面说的三个阶段，在代码里怎么实现？靠状态机。状态机是刷写流程的骨架，它决定了ECU在什么状态下该做什么事。

我画了一张状态机图，你看一眼就明白了：

这个状态机，说白了就是ECU刷写时的“交通规则”。每个状态只能做该做的事，不能乱跳。比如在MAIN_PROGRAM状态下，ECU只处理0x36传输数据请求，其他请求一概不理。

我的经验：状态机里一定要加超时处理。每个状态停留时间超过设定值（比如5秒），就自动跳转到错误状态。我曾经遇到过CAN总线被拔掉，ECU卡在MAIN_PROGRAM状态出不来，最后只能断电重启。

状态机代码示例（伪代码）

下面是一个简化的状态机实现，你看一下核心逻辑：

typedef enum {
    IDLE,
    PRE_PROGRAM,
    MAIN_PROGRAM,
    VERIFY,
    POST_PROGRAM,
    COMPLETE,
    ERROR
} FlashState;

FlashState currentState = IDLE;

void FlashStateMachine(void) {
    switch(currentState) {
        case IDLE:
            if(ReceivedDiagnosticRequest()) {
                currentState = PRE_PROGRAM;
            }
            break;
            
        case PRE_PROGRAM:
            if(DisableDTC() && StopCommunication()) {
                currentState = MAIN_PROGRAM;
            } else {
                currentState = ERROR;
            }
            break;
            
        case MAIN_PROGRAM:
            if(AllDataTransmitted()) {
                currentState = VERIFY;
            } else if(TimeoutOccurred()) {
                currentState = ERROR;
            }
            break;
            
        case VERIFY:
            if(CRC32CheckPassed()) {
                currentState = POST_PROGRAM;
            } else {
                currentState = ERROR;  // 触发回滚
            }
            break;
            
        case POST_PROGRAM:
            if(RestoreCommunication() && EnableDTC()) {
                currentState = COMPLETE;
            }
            break;
            
        case COMPLETE:
            ExecuteReset();
            break;
            
        case ERROR:
            HandleError();  // 回滚到旧版本
            break;
    }
}

你看，代码逻辑很清晰。每个case对应一个状态，做完该做的事就跳到下一个状态。这里我特别强调一下ERROR状态的处理——不能只是报个错就完事，得做回滚操作，把ECU恢复到刷写前的状态。

三个阶段与状态机的对应关系

最后，我把三个阶段和状态机做个对照，方便你理解：

刷写阶段	对应状态机状态	关键动作
预编程	PRE_PROGRAM	关闭DTC、停止通信、禁用执行器
主编程	MAIN_PROGRAM → VERIFY	数据传输、CRC校验
后编程	POST_PROGRAM → COMPLETE	恢复通信、启用DTC、复位

嗯，到这里刷写流程的核心内容就讲完了。记住一句话：流程是死的，但状态机是活的。实际项目中，你可能会根据ECU的具体需求调整状态机的细节，但三个阶段的大框架不要动。动了，就容易出问题。