第2章升级失败场景分析

2、升级失败场景分析：断电中断、Flash写入错误、固件校验失败、通信中断、版本不兼容

大家好，我是你们的老朋友。今天咱们聊聊升级失败的那些事儿。

说实话，做Bootloader这么多年，我见过太多升级失败的案例了。有的客户半夜打电话过来，说设备变砖了，语气那叫一个急。其实呢，大部分失败场景都是有规律可循的。你只要提前分析清楚，就能在代码里做好防护。

下面这五种场景，是我在实际项目中遇到最多的。咱们一个一个说。

2.1 断电中断

这是最常见的，也是最头疼的。你想想看，用户升级到一半，手一抖把电源拔了，或者家里跳闸了。这时候Flash里可能写了一半，新旧固件都不完整。

我有个血的教训。早年做一款智能电表，升级过程中断电，结果设备彻底起不来了。后来我加了个双备份机制，才彻底解决这个问题。

⚠️ 核心风险： 升级过程中断电，会导致Flash中数据不完整。设备可能卡在中间状态，既不能运行新固件，也无法回退到旧固件。

我的应对策略：

双备份区设计： 保留一个完整的旧固件副本。升级时先写备份区，校验通过后再切换。
关键点标记： 在Flash里放一个状态标记。每次写入前先标记“正在升级”，写完后标记“升级完成”。启动时检查这个标记，如果发现是“正在升级”，就自动回退。
电源监测： 如果硬件支持，加一个掉电检测电路。检测到电压下降时，立即停止Flash写入，保存关键状态。

2.2 Flash写入错误

Flash写入本身就有失败的概率。比如电压不稳、Flash寿命到了、或者写入时序不对。我遇到过最离谱的一次，是某款Flash芯片在高温下写入会随机出错。

为什么会这样？说白了，Flash的写入操作需要高压脉冲。如果供电质量不好，或者芯片本身有坏块，写入就会失败。

  💡 我的经验： 每次写入后，一定要做读回校验。别偷懒，这个步骤不能省。

具体做法：

写入前，先擦除目标扇区。
写入数据，每次写一页（通常是256字节或512字节）。
写入后，立即读回该页数据，与源数据逐字节比对。
如果比对失败，重试3次。如果3次都失败，标记该扇区为坏块，换一个扇区继续写。

// 伪代码示例：带校验的Flash写入
bool flash_write_with_verify(uint32_t addr, uint8_t* data, uint32_t len) {
    for (int retry = 0; retry < 3; retry++) {
        if (flash_write_page(addr, data, len) != OK) {
            continue;  // 写入失败，重试
        }
        // 读回校验
        uint8_t buffer[len];
        flash_read(addr, buffer, len);
        if (memcmp(data, buffer, len) == 0) {
            return true;  // 校验通过
        }
    }
    return false;  // 3次都失败
}

2.3 固件校验失败

固件在传输过程中可能被篡改，或者下载时发生了比特错误。我见过有人用劣质串口线，结果数据传过来全是乱码。

校验失败的原因其实就两个：一是数据在传输过程中损坏了，二是固件本身就不对（比如编译错了版本）。

🔧 我的建议： 至少做两层校验。第一层是CRC32或SHA256，确保数据完整性。第二层是签名验证，确保固件来源可信。

校验流程：

CRC校验： 固件包头部包含CRC32值。接收完固件后，计算整个固件的CRC，与头部值比对。不匹配就直接丢弃。
签名验证： 如果安全要求高，用RSA或ECDSA签名。只有用私钥签名的固件才能通过验证。这个我在做车规级产品时是强制要求的。
版本号检查： 固件头部包含版本号。升级前检查版本号是否高于当前版本，防止降级攻击。

2.4 通信中断

升级过程中，通信链路突然断了。比如WiFi信号不好、蓝牙断连、或者串口线被踢掉了。这时候固件只传了一半，怎么办？

我记得有一次做远程升级，用户在山里信号差，每次传到80%就断了。后来我加了断点续传功能，才搞定。

我的处理方案：

分包传输： 把固件分成多个小包，每个包有独立的序号和CRC。
断点续传： 接收端记录已收到的最大包序号。重新连接后，从断点处继续传，不用重头开始。
超时重试： 发送端设置超时时间。如果超过5秒没收到确认，就重发当前包。重试超过5次，就报错退出。

⚠️ 注意： 断点续传需要接收端有非易失性存储来保存进度。如果设备没有外部Flash，可以用内部Flash的最后几个扇区来存。

2.5 版本不兼容

这个坑我踩过好几次。新固件改了数据结构，或者换了通信协议，结果和旧版本不兼容。设备升级后，和服务器通信全乱了。

说白了，版本不兼容分两种：向前兼容和向后兼容。向前兼容是指新固件能处理旧数据，向后兼容是指旧固件能识别新数据。做升级时，至少要保证向前兼容。

我的避坑指南：

版本号规范： 用主版本号.次版本号.修订号。主版本号不同，表示不兼容升级。次版本号不同，表示功能增加但兼容。修订号不同，表示bug修复。
数据结构版本化： 所有存储在Flash中的数据结构，都要带一个版本字段。读取时根据版本号做兼容处理。
升级前检查： 在升级开始前，先检查新固件的兼容性标记。如果标记为不兼容，直接拒绝升级，并提示用户。

// 数据结构版本化示例
typedef struct {
    uint8_t version;  // 数据结构版本
    uint8_t data[100];
} AppConfig;

void load_config(AppConfig* cfg) {
    if (cfg->version == 1) {
        // 处理V1版本的数据
    } else if (cfg->version == 2) {
        // 处理V2版本的数据
    } else {
        // 未知版本，使用默认值
    }
}

小结

这五种场景，说白了就是升级路上的五个拦路虎。你只要在代码里把每种情况的处理逻辑都写清楚，设备基本就不会变砖。

我个人习惯是，在Bootloader的main函数里，先检查升级状态标记，再决定是继续升级还是回退。这样即使升级过程中断电，重启后也能自动恢复。

📚 课程目录

2、升级失败场景分析：断电中断、Flash写入错误、固件校验失败、通信中断、版本不兼容

2.1 断电中断

2.2 Flash写入错误

2.3 固件校验失败

2.4 通信中断

2.5 版本不兼容

小结