回滚触发机制：手动触发、自动触发与远程触发

回滚机制设计得好不好，触发逻辑占了七成功力。触发时机选错了，要么该滚的时候滚不回去，要么不该滚的时候瞎滚一通。我见过不少产品，看门狗复位后直接回滚，结果生产线上正常升级也被当成故障——那叫一个惨。

这一章咱们就把三种触发方式掰开揉碎了讲。手动、自动、远程，每种都有它的适用场景和坑。

手动触发：最朴素的保底手段

手动触发说白了就是给人留个后门。设备变砖了，总得有个办法让它活过来。

我习惯在 Bootloader 里留一个 GPIO 检测窗口。上电后 500ms 内，如果检测到特定引脚被拉低，就强制进入回滚流程。这个引脚通常接一个物理按键，或者干脆留个测试点。

// 手动触发回滚示例（伪代码）
void bootloader_main(void) {
    // 上电延迟 100ms，等 GPIO 电平稳定
    delay_ms(100);
    
    // 读取回滚触发引脚
    if (GPIO_ReadPin(ROLLBACK_PIN) == LOW) {
        // 用户强制要求回滚
        perform_rollback();
    }
    
    // 正常启动流程
    jump_to_application();
}

这里有个细节：GPIO 检测窗口不能太长，否则用户等得不耐烦；也不能太短，否则按键还没按下去窗口就过了。我个人习惯设 500ms~1s，配合一个 LED 闪烁提示用户「现在可以按了」。

自动触发：看门狗超时与 CRC 校验失败

自动触发是回滚机制的主力。设备没人守着，出了问题得自己判断、自己恢复。

看门狗超时触发

看门狗超时是最常见的自动触发方式。应用跑飞了、死锁了、或者升级后起不来，看门狗没人喂，系统复位。Bootloader 在复位后检查复位原因寄存器，如果发现是看门狗复位，就启动回滚。

但这里有个大坑：不是所有看门狗复位都要回滚。临时性的干扰也可能导致看门狗超时，直接回滚反而把好用的固件换掉了。

我曾经在一个电表项目上吃过这个亏。电表在强电磁干扰下偶尔会死机，看门狗复位后 Bootloader 直接回滚到旧版本。结果旧版本有个计量精度问题，用户投诉电费不准。后来我加了一个计数器：连续 3 次看门狗复位才触发回滚。

// 看门狗触发回滚逻辑
void check_watchdog_rollback(void) {
    if (RCC_GetResetFlag() == RCC_RESET_FLAG_IWDG) {
        // 读取 NVRAM 中的复位计数
        uint8_t reset_count = nvram_read(RESET_COUNT_ADDR);
        reset_count++;
        
        if (reset_count >= 3) {
            // 连续 3 次看门狗复位，执行回滚
            nvram_write(RESET_COUNT_ADDR, 0);
            perform_rollback();
        } else {
            nvram_write(RESET_COUNT_ADDR, reset_count);
            // 尝试再次启动应用
            jump_to_application();
        }
    }
}

CRC 校验失败触发

CRC 校验是固件完整性的最后一道防线。应用启动前，Bootloader 计算整个应用区的 CRC32，跟升级时存储的参考值比对。不一致就说明固件损坏了，直接回滚。

我建议做两级 CRC 校验：

• 快速校验：只校验应用头部 256 字节（包含中断向量表和关键配置），耗时短，适合每次启动都做。
• 全量校验：校验整个应用区，耗时较长，适合在升级完成后做一次。

校验类型	校验范围	耗时（典型值）	触发时机
快速校验	应用头部 256 字节	< 5ms	每次启动
全量校验	整个应用区	100ms~500ms	升级完成后、定期巡检

远程触发：云端说了算

远程触发是 IoT 设备的标配。服务器发现某个版本的固件有严重 bug，直接下发指令让设备回滚到上一个稳定版本。

远程触发的实现方式通常有两种：

1. MQTT/CoAP 指令：服务器下发一个 JSON 指令，设备解析后执行回滚。
2. 标志位轮询：设备定期向服务器查询「是否有回滚指令」，有则执行。

我个人更推荐第二种。原因很简单：指令下发可能丢包，但轮询是设备主动发起的，可靠性更高。而且轮询可以顺便上报设备状态，一举两得。

// 远程回滚指令处理（MQTT 回调）
void on_mqtt_message(char *topic, char *payload) {
    if (strcmp(topic, "device/rollback") == 0) {
        // 解析指令
        json_t *root = json_parse(payload);
        const char *action = json_get_string(root, "action");
        
        if (strcmp(action, "rollback") == 0) {
            // 设置回滚标志
            nvram_write(ROLLBACK_FLAG_ADDR, 0xAA55);
            // 软件复位
            NVIC_SystemReset();
        }
    }
}

三种触发方式的对比与选择

触发方式	适用场景	优点	缺点
手动触发	现场维护、产线测试	简单可靠，不依赖网络	需要人工干预
看门狗超时	应用死锁、跑飞	自动恢复，无需外部干预	可能误触发，需要防抖
CRC 校验失败	固件损坏、Flash 错误	检测准确，覆盖硬件故障	增加启动时间
远程触发	批量回滚、版本管控	集中管理，响应快	依赖网络，有安全风险

实际项目中，这三种方式通常是组合使用的。我最近做的一个智能网关项目，就同时用了全部三种：现场维护按按键手动回滚，应用死机了看门狗自动回滚，服务器发现漏洞了远程批量回滚。三重保险，基本没出过问题。

本章核心逻辑图

下面这张图把三种触发方式的流程和关系画清楚了。你可以把它贴在工位上，设计时对照着来。