ESP32 OTA (Over-the-Air Update) functionality allows IoT devices to update firmware over a wireless network, greatly improving the maintainability and scalability of products. In the age of IoT, frequent firmware updates have become more common. The ESP32 OTA feature enables devices in fields such as smart homes and industrial automation to stay updated, improving user experience.

Introduction

OTA (Over-The-Air) refers to the wireless communication technology that directly pushes software or firmware updates to devices, enabling remote upgrades and maintenance without physical interaction or manual intervention. This is particularly useful for modern IoT devices and embedded systems.

This article delves into the ESP32 OTA partition table design, helping you better understand how to partition OTA sections to enhance system flexibility and enable efficient firmware updates.

In ESP32, the partition table is a crucial concept, defining how the device’s internal flash memory is used. Each partition entry describes a specific memory area, used to store applications, data, settings, and more.

For ESP32 OTA updates, we typically use two or more application partitions to implement version control and rollback mechanisms. This way, even if a new firmware version causes issues, the device can switch to the previous stable partition, ensuring system stability.

Development Environment

Before starting your programming, make sure to complete the following preparations:

• Install ESP-IDF (version 4.4 or higher): ESP-IDF is the official development framework for programming the ESP32, and it supports multiple operating systems such as Windows, macOS, and Linux.
• ESP32 Development Board: An ESP32 board is required.
• Other reference articles.

Basic OTA Partition Design

In the most basic ESP32 OTA partition design, we use ota_0 and ota_1 as two application partitions. The device will select one of the partitions to run the application on boot, while the other partition is reserved for subsequent ESP32 OTA updates.

Name,   Type, SubType, Offset,   Size, Flags
nvs,      data, nvs,     ,        0x4000,
otadata,  data, ota,     ,        0x2000,
phy_init, data, phy,     ,        0x1000,
ota_0,    app,  ota_0,   ,        1M,
ota_1,    app,  ota_1,   ,        1M,

Design Explanation:

• nvs: Used to store device non-volatile settings (e.g., Wi-Fi configuration).
• otadata: Stores data related to the ESP32 OTA update process, including the current active application partition and other related metadata.
• phy_init: Stores data for physical layer initialization.
• ota_0 and ota_1: These two partitions store different versions of the application. The device will boot from the partition indicated in the otadata entry.

OTA Partition with Encryption

To enhance security, encryption support can be added, especially when sensitive data needs to be encrypted. For example, an encrypted nvs_key partition can be used to store encrypted NVS data, ensuring firmware and data transmissions during OTA updates are encrypted.

Name,   Type, SubType, Offset,   Size, Flags
nvs,      data, nvs,     ,        0x4000,
otadata,  data, ota,     ,        0x2000,
phy_init, data, phy,     ,        0x1000,
factory,  app,  factory, ,        1M,
ota_0,    app,  ota_0,   ,        1M,
ota_1,    app,  ota_1,   ,        1M,
nvs_key,  data, nvs_keys,,        0x1000, encrypted

Design Explanation:

• nvs_key: Stores encrypted NVS data. This is an important security feature, ensuring that even if the device is physically tampered with, its configuration data remains secure.
• The encrypted: flag indicates that the data in this partition is stored encrypted.

OTA Partition Design with Crash Log Support

For scenarios where error information or crash logs need to be collected, you can include a coredump partition in the partition table. This ensures that even if the application crashes, the device can retain debugging information to help developers identify the issue.

Name,   Type, SubType, Offset,   Size
nvs,      data, nvs,     ,         0x4000,
otadata,  data, ota,     ,         0x2000,
phy_init, data, phy,     ,         0x1000,
factory,  0,    0,       ,         1M,
coredump, data, coredump,,         64K,
ota_0,    0,    ota_0,   ,         1M,
ota_1,    0,    ota_1,   ,         1M,

Design Explanation:

• coredump: This partition stores core dump information when the application crashes, typically small data like crash stacks or error logs, often a few dozen KB in size.

Partition Table Comparison

• Standard configuration: Suitable for basic needs without special data or diagnostic requirements.
• Encrypted NVS configuration: Protects sensitive data, ideal for applications handling confidential data.
• Core dump configuration: Useful for error diagnostics, enabling developers to analyze crashes or bugs.

Conclusion

OTA functionality is an essential part of modern embedded systems, and a well-designed partition table is key to successfully implementing OTA updates. Understanding ESP32’s OTA partition design helps developers manage applications and data effectively, enhancing system flexibility and reliability. Whether using a standard dual-partition design or more complex designs supporting encryption and crash logs, developers can tailor the configuration to different application scenarios for more efficient remote management and upgrades.