1. 从一次“刷废了”的深夜说起凌晨两点我盯着串口监视器里那一串不断重复的rst:0x3 (SW_RESET), boot:0x13 (SPI_FAST_FLASH_BOOT)心里凉了半截。手上这块 ESP32 开发板刚被我刷进一个自己改过的固件结果启动到一半就卡死重启、断电、按住 BOOT 键重来全都没用。那一刻我脑子里只有一个念头这玩意儿是不是彻底变砖了后来折腾了大半夜才搞明白ESP32 这芯片本身有个非常关键的硬件特性——它压根就不存在传统意义上“刷死就报废”的砖。只要芯片没被物理烧毁你永远可以通过串口重新烧录。真正让人头疼的不是“能不能救回来”而是“设备装在墙上、埋在地下、放在客户手里你根本够不着串口”。这才是固件升级这件事真正的痛点。所以这篇文章我想聊的不是“怎么救砖”而是更实际的问题怎么让 ESP32 在固件升级失败时自己救自己。答案就是标题里说的双分区加自动回滚。我会把 OTA 升级的完整机制、分区表怎么设计、回滚标志位怎么用、代码怎么写、坑在哪里全部掰开揉碎讲一遍。不管你是刚上手 ESP32 的新手还是已经在做量产固件的老手这套方案都能直接抄作业。先说结论ESP32 的 OTA 机制配合双分区和自动回滚能做到“新固件启动失败自动退回旧固件”成功率接近百分之百。前提是你得把分区表和回滚逻辑配对这两块任何一块出问题回滚就是摆设。2. 为什么 ESP32 不会真的变砖2.1 芯片层面的“不死之身”从哪来要理解回滚机制得先搞清楚 ESP32 的启动链路。ESP32 芯片内部有一块 ROM这块 ROM 是出厂就固化死的你刷不掉也改不了。上电之后CPU 第一件事就是执行 ROM 里的引导代码这段代码会去读 Flash 里一个固定偏移地址的内容也就是我们常说的 bootloader。关键点来了bootloader 和应用程序是分开存放的。你平时用 Arduino IDE 或者 ESP-IDF 烧录的时候烧进去的其实是三部分东西——bootloader、分区表、应用程序。应用程序刷坏了bootloader 还在bootloader 刷坏了ROM 里的引导代码还能通过串口把你拉回来。这就是为什么 ESP32 几乎不可能真正变砖。我打个比方。传统单片机像是把钥匙和锁焊死在一起钥匙断了锁就废了。ESP32 更像是小区门禁系统ROM 是物业总控室bootloader 是单元门禁应用程序是你家房门。你家房门锁坏了物业总控室照样能派人来修单元门禁也还能用。只要总控室还在一切都有救。2.2 串口救砖的底层逻辑那具体怎么救核心就是让芯片进入下载模式。ESP32 有个自动下载电路通常由 USB 转串口芯片的 DTR 和 RTS 两个信号控制 EN 和 IO0 引脚。当你点击烧录按钮时工具会拉低 IO0 再复位芯片芯片一上电检测到 IO0 是低电平就会跳过 Flash 里的程序直接进入 ROM 的串口下载模式。手动操作也一样按住 BOOT 键不放点一下 EN 键或者断电再上电然后松开 BOOT 键芯片就进下载模式了。这时候你用 esptool 或者任何烧录工具都能重新写入固件。我实测过哪怕把整个 Flash 擦得干干净净只要芯片没坏照样能救回来。注意真正会让 ESP32 彻底报废的情况只有两种——芯片物理损坏或者 Flash 芯片被写保护且你忘了密码。前者是硬件问题后者是安全机制跟“刷坏固件”完全是两码事。2.3 那为什么还要做回滚既然串口能救为什么还要费劲搞双分区和自动回滚因为现实场景里你根本够不着串口。设备装在十米高的路灯杆上、埋在农田的土壤传感器里、卖到客户手里装在配电箱里你不可能每次都派人去现场插 USB 线。这时候唯一的升级通道就是 OTA而 OTA 一旦失败设备就失联了失联的设备等于砖。所以回滚机制解决的不是“芯片能不能救”而是“设备能不能自己救自己”。这是两个完全不同层面的问题。前者是芯片特性后者是固件设计。标题里说的“回答这个问题”答案其实分两层芯片层面不会变砖设备层面需要靠双分区和回滚来保证。3. 双分区方案到底是怎么设计的3.1 分区表是整套机制的骨架ESP32 的 Flash 分区表决定了每一块存储空间用来干什么。默认的单分区方案里应用程序只有一个分区OTA 升级时新固件直接覆盖旧固件覆盖到一半断电两边都不完整设备就起不来了。双分区方案的核心思路是准备两个应用程序分区一个在跑一个在待命。典型的双分区表长这样# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x5000, otadata, data, ota, 0xe000, 0x2000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x140000, ota_0, app, ota_0, 0x150000, 0x140000, ota_1, app, ota_1, 0x290000, 0x140000,这里有几个关键点。factory是出厂固件分区ota_0和ota_1是两个 OTA 槽位。otadata分区只有 8KB但它才是整套回滚机制的“大脑”记录着当前该从哪个槽位启动、哪个槽位是有效的、有没有待验证的新固件。我见过很多人分区表写错最常见的就是otadata大小给成 0x1000 或者干脆忘了加。otadata标准大小是 0x2000里面存两份 ota_select 数据结构互为备份。给小了会导致写入越界回滚直接失效。3.2 otadata 里到底存了什么otadata分区里存的是esp_ota_select_entry_t结构核心字段就两个ota_seq和ota_state。ota_seq是个递增的序号用来判断哪个槽位的固件更新ota_state标记这个槽位的状态常见取值有ESP_OTA_IMG_NEW、ESP_OTA_IMG_PENDING_VERIFY、ESP_OTA_IMG_VALID、ESP_OTA_IMG_INVALID等。启动流程是这样的bootloader 上电后读otadata找到ota_seq最大的那个槽位再看它的状态。如果是VALID直接启动如果是PENDING_VERIFY说明这是刚升级还没验证过的新固件bootloader 会先启动它但心里记着一笔账——如果这个固件在限定时间内没有主动调用esp_ota_mark_app_valid_cancel_rollback()把自己标记为有效下次重启就回滚到旧槽位。这个设计非常巧妙。它把“固件是否健康”的判断权交给了固件自己。你的应用程序启动后连上 WiFi、连上服务器、初始化完所有外设确认一切正常再调用那个函数“盖章确认”。如果固件有 bug启动到一半就崩了根本没机会盖章重启几次后 bootloader 就自动回滚。3.3 双分区和单分区的取舍有人会问双分区占了两倍 Flash 空间值不值我的看法是看你做什么产品。如果是玩具级别的实验板Flash 有 4MB单分区跑跑也行刷坏了插串口救。但只要是量产设备、远程部署、或者对可靠性有要求的场景双分区是底线没有商量余地。而且双分区还有个额外好处升级过程不影响当前运行。新固件是先完整写入待命槽位写完之后才切换启动标志。写入过程中设备照常运行旧固件哪怕写到一半断电旧固件依然完好下次启动还是从旧槽位起来。这就是所谓的 A/B 升级工业界用了几十年的成熟方案。Flash 空间不够怎么办可以砍掉factory分区只用ota_0和ota_1两个槽位。出厂时直接把固件烧进ota_0otadata初始化为从ota_0启动。这样能省下一个分区的空间代价是没有“出厂兜底固件”但双槽位互备已经足够安全。4. 自动回滚的代码实现与关键细节4.1 用 ESP-IDF 实现完整回滚流程先看核心代码。下面这段是 OTA 升级加回滚验证的完整骨架基于 ESP-IDF 的esp_ota_ops组件#include esp_ota_ops.h #include esp_http_client.h #include esp_https_ota.h void ota_task(void *pvParameter) { esp_http_client_config_t config { .url http://your-server/firmware.bin, .timeout_ms 10000, }; esp_https_ota_config_t ota_config { .http_config config, }; esp_https_ota_handle_t handle NULL; esp_err_t ret esp_https_ota_begin(ota_config, handle); if (ret ! ESP_OK) { ESP_LOGE(TAG, OTA begin failed); vTaskDelete(NULL); return; } while (1) { ret esp_https_ota_perform(handle); if (ret ! ESP_ERR_HTTPS_OTA_IN_PROGRESS) { break; } } if (esp_https_ota_finish(handle) ESP_OK) { ESP_LOGI(TAG, OTA success, restarting...); esp_restart(); } else { ESP_LOGE(TAG, OTA failed); } vTaskDelete(NULL); }这段代码负责把新固件下载并写入待命槽位写完调用esp_restart()重启。重启后 bootloader 会启动新固件但此时新固件的状态是PENDING_VERIFY。接下来就是最关键的一步——在新固件的初始化流程里确认一切正常后调用esp_err_t err esp_ota_mark_app_valid_cancel_rollback(); if (err ! ESP_OK) { ESP_LOGE(TAG, Failed to mark app valid); }这一行就是“盖章”。盖了章新固件才算正式转正。没盖章下次重启就回滚。4.2 验证逻辑该放在哪里这里有个非常容易踩的坑盖章的时机太早或太晚都不行。太早比如在app_main开头就盖章那固件后面崩溃了也回滚不了因为已经转正了。太晚比如等设备连上云端、跑完一整套自检才盖章万一网络环境差设备还没盖章就重启了会误触发回滚。我的经验是把盖章点放在“核心功能自检通过之后业务逻辑启动之前”。具体来说WiFi 连上了、关键外设初始化成功了、看门狗喂上了这时候盖章。至于云端连接、数据上报这些依赖外部环境的不纳入盖章条件否则网络一抖动就回滚用户体验极差。如果你用的是 Arduino 框架ESP32 的 Arduino 核心也封装了对应接口#include Update.h // OTA 写入完成后 if (Update.end(true)) { esp_ota_mark_app_valid_cancel_rollback(); ESP.restart(); }注意 Arduino 里Update.end(true)的参数表示“即使校验失败也继续”一般建议传true配合后续的mark_app_valid做双重确认。4.3 回滚次数的控制默认情况下ESP-IDF 允许新固件尝试启动若干次超过次数才回滚。这个次数由CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE和相关的重试配置控制。在menuconfig里可以找到Bootloader config下的Enable app rollback support打开它才会启用回滚。我建议把重试次数设成 2 到 3 次。设成 1 次太激进偶尔一次上电时序问题就回滚了设成 5 次以上又太迟钝设备反复重启半天才回滚中间这段时间业务是中断的。3 次是个比较平衡的值实测下来误判率很低。提示回滚功能必须在 bootloader 配置里显式打开默认是关闭的。很多人代码写对了但忘了开这个选项结果新固件崩了也不回滚白白浪费一晚上排查。5. 实操过程中踩过的坑与排查技巧5.1 分区表偏移地址对不齐这是新手最容易犯的错。ESP32 的应用程序分区起始地址必须按 0x10000 对齐也就是 64KB 边界。我见过有人把ota_0的 offset 写成 0x150000 没问题但把ota_1写成 0x280000结果两个分区重叠了写入时直接报错。正确的做法是让每个应用分区大小一致且 offset 严格按分区大小递增。比如factory从 0x10000 开始、大小 0x140000那ota_0就从 0x150000 开始ota_1从 0x290000 开始。用idf.py partition-table命令可以生成并校验分区表烧录前跑一遍能省很多事。5.2 otadata 状态异常导致启动循环有一次我遇到设备无限重启串口日志显示 bootloader 反复在ota_0和ota_1之间切换。查了半天发现是otadata分区被写坏了两个 ota_select 结构的 CRC 都对不上bootloader 只能退回到factory分区但我的分区表里又没定义factory于是死循环。解决办法有两个。一是确保otadata分区大小给足 0x2000并且不要在这个区域做任何自定义读写。二是如果确实需要恢复用 esptool 擦除otadata区域esptool.py --port /dev/ttyUSB0 erase_region 0xe000 0x2000擦完之后 bootloader 会重新初始化 otadata从默认槽位启动。5.3 OTA 下载中断后的残留数据OTA 下载过程中如果网络断了待命槽位里会残留半截固件。这时候otadata里的状态还是旧的bootloader 不会去启动那个残缺槽位所以设备本身没事。但下次再 OTA 时如果直接往同一个槽位写可能会因为 Flash 没擦干净导致校验失败。稳妥的做法是每次 OTA 开始前先调用esp_ota_get_next_update_partition()拿到目标分区然后esp_ota_begin()会自动擦除该分区。不要手动去擦交给 API 处理避免擦错区域。5.4 常见问题速查表现象可能原因排查方向新固件启动后立即回滚未调用 mark_app_valid检查盖章代码是否执行设备无限重启不回滚回滚功能未开启menuconfig 里打开 rollbackOTA 写入报错分区表偏移重叠用 partition-table 命令校验回滚后旧固件也起不来factory 分区缺失或损坏检查分区表定义串口日志显示 invalid header固件与分区不匹配确认烧录地址和分区表一致这张表是我自己攒下来的每次遇到问题先对照一遍能解决八成以上的情况。6. 几个容易被忽略的进阶细节6.1 固件签名与安全启动的影响如果你的产品开了安全启动Secure Boot和 Flash 加密OTA 流程会多一层签名校验。新固件必须用对应的私钥签名否则 bootloader 直接拒绝启动连回滚的机会都不给。这时候回滚机制依然有效但前提是旧固件本身是合法签名的。我建议在开发阶段先不开安全启动把回滚逻辑跑通量产前再打开。因为安全启动一旦开启烧录和调试都会麻烦很多混在一起排查问题会让人崩溃。6.2 回滚后的状态上报设备回滚了你得知道。否则你永远不知道新固件有问题还在纳闷为什么用户反馈功能没变化。我的做法是在app_main里检查当前运行的是哪个分区如果发现是从ota_0回滚到了ota_1就通过 MQTT 或者 HTTP 上报一条“回滚事件”到服务器。获取当前分区用esp_ota_get_running_partition()对比esp_ota_get_boot_partition()就能判断是否发生了回滚。这个信息对运维极其有价值能让你第一时间发现固件质量问题。6.3 双分区之外的第三种选择除了 A/B 双分区还有一种方案是“单分区加外部备份”。把旧固件备份到外部 Flash 或者 SD 卡升级失败时从外部恢复。这种方案适合 Flash 空间极度紧张的场景但恢复速度慢可靠性也不如双分区。我个人还是推荐双分区省心。另外ESP32-S3、ESP32-C3 这些新芯片的 Flash 普遍更大4MB 起步8MB 常见双分区完全放得下。没必要为了省那点空间牺牲可靠性。7. 我个人的几点实操体会折腾了这么多块板子我最大的体会是回滚机制的价值不在于技术多复杂而在于它把“远程设备失联”这个最坏情况变成了“自动恢复”这个可控情况。一个没有回滚的 OTA 系统本质上是在赌网络稳定、赌固件没 bug、赌用户不会在升级时断电。这三个赌注任何一个输了设备就变砖。而双分区加自动回滚把这三种风险全部兜住了。网络断了旧固件继续跑固件有 bug自动回滚升级时断电旧固件完好无损。这套机制跑通之后我做远程升级的心态完全变了以前每次推送固件都提心吊胆现在推完该睡觉睡觉第二天看回滚上报就行。最后分享一个小技巧在量产固件里把回滚验证的超时时间设得比开发阶段长一点。开发时你可能设 30 秒量产时建议设 60 到 90 秒给设备充足的时间完成 WiFi 连接和外设初始化。这个参数在menuconfig的Bootloader config里能找到叫App rollback retry timeout相关的配置项。别小看这几十秒的差别它能显著降低误回滚的概率。
