📚 课程目录第2章基础知识

2、基础知识：ESP32的Flash分区表结构、OTA分区（otadata、app0、app1）的作用与配置

ESP32 的 OTA（Over-The-Air）升级能力，本质上依赖于其 Flash 存储器的分区管理机制。理解分区表（Partition Table）是掌握 OTA 的前提——它决定了固件可以放在哪里、OTA 状态记录在哪里、以及系统如何安全地在新旧固件之间切换。本章将深入剖析 ESP32 的 Flash 分区表结构，重点讲解 otadata、app0、app1 三个关键分区的职责、配置方法以及它们在回滚策略中的底层逻辑。

2.1 ESP32 Flash 分区表的核心原理

ESP32 的 Flash 存储器被划分为多个逻辑区域，每个区域称为一个“分区”（Partition）。分区表是一个固定格式的 CSV 文件（通常命名为 partitions.csv），在编译时被转换为二进制格式，并烧录到 Flash 的固定偏移地址 0x8000 处。系统启动时，Bootloader 会读取该表，根据表中的类型（Type）、子类型（Subtype）和偏移量（Offset）来定位各个分区。

分区表的核心价值在于：将固件、文件系统、配置数据、OTA 状态等不同性质的数据隔离存储。这样既避免了相互覆盖，又为 OTA 升级提供了“双 Bank”切换的基础。一个典型的 4MB Flash 分区表如下：

# Name,   Type, SubType, Offset,   Size,    Flags
nvs,      data, nvs,     0x9000,   0x5000,
otadata,  data, ota,     0xe000,   0x2000,
app0,     app,  ota_0,   0x10000,  0x1C0000,
app1,     app,  ota_1,   0x1D0000, 0x1C0000,
spiffs,   data, spiffs,  0x390000, 0x70000,

上述配置中，app0 和 app1 各占 1.75MB，otadata 占 8KB，nvs 占 20KB，剩余空间分配给 SPIFFS 文件系统。Bootloader 启动时，会先读取 otadata 分区中的状态信息，决定从 app0 还是 app1 加载应用程序。

关键点：分区表的偏移量（Offset）必须严格对齐 0x10000（64KB）的边界，这是 ESP32 硬件的要求。如果手动修改偏移量，务必保持 64KB 对齐，否则 Bootloader 可能无法正确识别分区。

2.2 OTA 三大核心分区：otadata、app0、app1 的职责

OTA 升级涉及三个关键分区，它们各自承担不同的职责，共同构成一个完整的“可回滚”升级闭环。

分区名	类型/子类型	典型大小	核心职责	关键特性
otadata	data / ota	8KB（0x2000）	记录当前应启动的 APP 分区编号、OTA 状态、回滚计数器	两个 sector 交替写入，防止写入中断导致状态丢失
app0	app / ota_0	1.75MB（典型）	存放第一个固件镜像，通常为出厂固件或上一稳定版本	与 app1 大小必须完全一致
app1	app / ota_1	1.75MB（典型）	存放第二个固件镜像，用于接收 OTA 下载的新固件	升级时写入，校验通过后切换启动

otadata 的工作机制：它内部维护了一个 esp_ota_select_entry_t 结构体，包含 ota_seq（序列号）、seq（回滚计数）和 crc 校验值。每次系统启动时，Bootloader 会比较两个 sector 中的信息，选择序列号较大且 CRC 正确的那个作为当前启动项。当 OTA 升级完成后，新固件会更新 otadata，将启动指向 app1；如果 app1 启动失败（例如应用程序崩溃重启超过设定次数），Bootloader 会自动回退到 app0。

经验提醒：otadata 分区虽然只有 8KB，但它内部采用“双 sector 交替写入”策略。这意味着即使升级过程中突然断电，otadata 中至少有一个 sector 是完整的，系统仍能恢复到上一个可用状态。这是 ESP32 OTA 可靠性的重要保障。

2.3 分区表的配置方法与操作流程

在实际项目中，配置 OTA 分区表通常遵循以下流程：

确定 Flash 容量：通过 esptool.py flash_id 或查看芯片丝印确认 Flash 大小（常见 4MB、8MB、16MB）。
设计分区布局：根据固件大小、文件系统需求、OTA 升级频率来分配各分区大小。固件分区（app0/app1）必须大小一致，且建议预留 20% 余量以应对固件增长。
编写 partitions.csv：在项目根目录创建或修改分区表文件，并在 menuconfig 中指定该文件路径（CONFIG_PARTITION_TABLE_CUSTOM_FILENAME）。
编译并烧录：执行 idf.py build 后，使用 idf.py -p PORT flash 烧录。首次烧录时，Bootloader 会默认从 app0 启动。
验证分区表：使用 idf.py partition-table 命令查看生成的分区表二进制内容，或通过串口日志确认 Bootloader 打印的分区信息。

以下是一个针对 8MB Flash 的 OTA 分区配置示例，它额外增加了 coredump 分区用于故障诊断：

# Name,      Type, SubType, Offset,   Size,     Flags
nvs,         data, nvs,     0x9000,   0x6000,
otadata,     data, ota,     0xf000,   0x2000,
app0,        app,  ota_0,   0x10000,  0x300000,
app1,        app,  ota_1,   0x310000, 0x300000,
coredump,    data, coredump,0x610000, 0x10000,
spiffs,      data, spiffs,  0x620000, 0x1E0000,

风险提示：如果 app0 和 app1 的大小不一致，OTA 升级时写入 app1 的固件可能超出分区边界，导致数据写入到相邻分区（如 spiffs），造成文件系统损坏。务必在编译时检查 idf.py size 输出的固件大小，确保其小于分区容量。

2.4 案例拆解：从“升级失败”到“自动回滚”的完整链路

下面通过一个实际工程案例，展示分区表配置和 otadata 机制如何协同工作，实现安全的 OTA 升级与回滚。

项目背景：某智能网关设备使用 ESP32-WROOM-32E（4MB Flash），原固件版本 v1.2 运行在 app0。开发团队发布了 v1.3 版本，修复了 Wi-Fi 断线重连的 bug，但新版本在特定路由器环境下存在内存泄漏问题。

初始现象：设备通过 MQTT 收到 OTA 升级指令，下载 v1.3 固件（约 1.2MB）到 app1 分区。写入完成后，系统调用 esp_ota_set_boot_partition() 将 otadata 指向 app1，并自动重启。

关键参数与日志：

I (3042) esp_ota: OTA Succeed, Rebooting...
I (3050) boot: OTA app1 is the current running app
I (3100) app: Firmware version: 1.3
...
E (15000) app: Memory allocation failed! (heap: 10240 bytes)
E (15000) app: Restarting in 5 seconds...

分析判断过程：v1.3 固件启动后，在 15 秒内因内存分配失败触发看门狗重启。由于 ESP32 的 OTA 机制默认启用了“启动回滚”（CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE），Bootloader 检测到 app1 连续 3 次启动失败后，自动将 otadata 回退到 app0，并启动 v1.2 固件。

实际操作步骤：

在 menuconfig 中确认启用了 CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE 和 CONFIG_BOOTLOADER_APP_ANTI_ROLLBACK（防回滚，可选）。
在应用程序中调用 esp_ota_mark_app_valid_cancel_rollback() 来标记固件“运行正常”。该函数应在系统初始化完成、关键自检通过后调用。
如果 v1.3 固件在启动早期就崩溃，未调用上述标记函数，Bootloader 会在连续 3 次失败后自动回滚。

结果对比：回滚后，设备恢复至 v1.2 稳定运行，网络连接正常。开发团队通过远程日志定位到内存泄漏点，在 v1.4 中修复后重新发布。

风险与代价：回滚期间设备会有约 1-2 分钟不可用（反复重启尝试）。此外，如果启用了 CONFIG_BOOTLOADER_APP_ANTI_ROLLBACK，则无法回退到旧版本，这要求开发团队必须确保新固件质量。

复盘经验：OTA 升级不仅仅是“下载-写入-重启”三个步骤，更是一个“验证-确认-回退”的闭环。合理的分区表配置和 otadata 策略，能将升级失败的影响控制在最小范围。

2.5 常见误区与总结复盘

在实际开发中，工程师在分区表配置和 OTA 使用上常犯以下错误：

误区一：忽略分区表对齐要求。手动修改偏移量时未保持 64KB 对齐，导致 Bootloader 无法识别分区，设备变砖。
误区二：app0 和 app1 大小不一致。编译时未检查固件大小，导致 OTA 写入时覆盖了相邻分区。
误区三：未调用 esp_ota_mark_app_valid_cancel_rollback()。即使新固件运行正常，也会在每次重启时被误判为“启动失败”，最终触发回滚。
误区四：otadata 分区被误擦除。某些量产工具会全片擦除 Flash，导致 otadata 丢失，设备无法确定启动哪个 APP 分区。

总结：ESP32 的 OTA 分区表设计是嵌入式系统“安全升级”思想的典型体现。通过将固件分为 app0/app1 双 Bank，并利用 otadata 记录状态，系统实现了“升级失败可回退”的容错机制。在实际项目中，建议遵循以下最佳实践：

始终保留一个已知良好的出厂固件在 app0，将 app1 作为“试验田”。
在固件中实现“启动自检 + 运行确认”机制，调用 esp_ota_mark_app_valid_cancel_rollback() 的时机应尽量延后，确保系统核心功能已稳定运行。
定期检查 Flash 剩余空间，避免因分区表配置不合理导致 OTA 升级空间不足。
在量产阶段，使用 esptool.py erase_region 单独擦除 app1 分区，而不是全片擦除，以保留 otadata 和 nvs 数据。