Home > On-Demand Archives > Theatre Talks >

Making robust FUOTA in ESP32 using Rollback

Pedro Bertoleti - Watch Now - Duration: 42:15

Making robust FUOTA in ESP32 using Rollback
Pedro Bertoleti

Firmware Update Over-The-Air (FUOTA) is a must-have feature in all IoT-like embedded solutions in operation today, once FUOTA can be the only possible and affordable solution for fixing some bugs, security flaws and other software malfunctions in devices in the field, using internet to provide new firmware devices located anywhere in the world. But, how do we ensure robustness to FUOTA process?

One big ally to add robustness to FUOTA process is the rollback resource. Using rollback, in case of bad firmware update (caused by some predictable or unpredictable reason), the embedded device can automatically get back to the last firmware version. It means, in case of bad firmware update, they can automatically recover themselves, without having any bricked device in the field, and requiring zero human intervention.

This presentation will show how to use rollback in FUOTA for ESP32 microcontroller, including a full demo of this process.

You can access the source code covered in this presentation at the following url: https://github.com/phfbertoleti/esp32_fuota_with_rollback

M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

Matthias
Score: 0 | 12 months ago | 1 reply

Pedro, thanks a lot for the talk.
I have a question regarding the factory partition. Is there any case or way where the system can fall back to the factory partition after a good FW was installed to one OTA partitions?
Background of the question is that I do use OTA on the ESP32 but due to space concerns I did eliminate the factory partition and have only two OTA partitions (beside the nvs and otadata). It will install via USB/UART with no problems (I assume on the ota_0 but actually never checked) and OTA updates run fine as well.

phfbertoleti@gmail.com
Score: 0 | 12 months ago | no reply

Hi Matthias.
First of all, thank you very much for watching the session and for the compliments!
As far as I know, after a good FW update AND after marking the current OTA partition as valid, there's no possibility of falling back to factory partition. Assuming a partition table that has factory partition in it, there'll be fallback to factory partition only if bad firmware is sent in the first FW update.

I've to admit I've never used a partition table without factory partition before. However, after some research, I've found this in official ESP32 forum: https://esp32.com/viewtopic.php?t=14337 . Therefore, as bootloader will automatically consider OTA_0 the first app partition, there isn't chance of system trying to fall back to an nonexistent factory partition.

Any questions remain? In case of new questions, please, feel free to ask, and I'll answer you as soon as possible.

Best Regards,
Pedro Bertoleti

Thomas.Schaertel
Score: 1 | 12 months ago | 1 reply

Pedro, very nice talk, well structured and presented! How did you manage the nvs data structures used by different versions of your firmware? Mostly a firmware update comes with an update to data... and that is not easy to switch between different versions either!
Also: Do you offer a public GitHub repo with the sample code you showed?

phfbertoleti@gmail.comSpeaker
Score: 0 | 12 months ago | no reply

Hi Thomas.

First of all, thank you very much for watching the session and for the compliments! The answers to your questions are below:

  1. How did you manage the nvs data structures used by different versions of your firmware?
    Answer: in ESP32, the NVS data is stored in a particular / dedicated partition called NVS partition. As the FUOTA process works only on ota_1 and ota_2 partitions, NVS partition remains untouched during FUOTA process. In the particular code for this presentation, the NVS partition structure (pair of key-data stored in NVS) is the same for both versions used, not requiring to switch or alternate between different NVS data structurization.
    However, when this data strructurization is needed ( = NVS structure isn't the same in a recent updated firmware version), it's a bit tricky to enure the compatibility, and how to do this is particullar to a solution or the way developer uses the NVS. As a good practice, considering NVS stores data in key-data pairs, I usually "fragment" the data the more I can, in order to have more key-data pairs rather than just a big (or few bigs) blob of data. By doing this, each piece of information is stored in one key-data pair in NVS, and then it's easier to add, edit or delete key-data pairs to ensure NVS compatibility between different firmware versions. Of course, this approach I suggested requires this NVS structurization to be implemented since the very first firmware version.

  2. Do you offer a public GitHub repo with the sample code you showed?
    Answer: Yes, the full code used in this presentation is available in: https://github.com/phfbertoleti/esp32_fuota_with_rollback

Any questions remain? In case of new questions, please, feel free to ask, and I'll answer you as soon as possible.

Best Regards,
Pedro Bertoleti

OUR SPONSORS