When doing espflash→OTA→espflash, (sometimes?) the boot partition is not set

[AlyoshaVasilieva]

Basic overview, might be wrong:

1. Flash with a partition table that has ota_0 and ota_1; it presumably flashes to ota_0
2. Perform an OTA update to a firmware with changed behavior, which will write to ota_1 (the not-in-use partition) and set that as the boot partition
3. Flash with espflash again, again using a firmware that behaves differently

The result is that the ESP32 continues to behave as if step 3 never happened. I assume that it's always flashing to ota_0 and not setting it as the boot partition, so the ESP simply continues booting from ota_1.

I'm using current git version of espflash and an ESP32-C3. I accidentally made a String that slowly expands infinitely, did an OTA, then tried to fix it repeatedly using USB flashes that did not change the running code. Above is my best guess at what's going wrong.

ESP-IDF's otatool can set the boot partition, according to this doc. Alternatively erasing the otadata partition should also reset to ota_0.

Although I'm not entirely sure the description/repro is right, running otatool.py --port COM3 switch_ota_partition --slot 0 resulted in it running the firmware I was trying to run, so I'm fairly certain that the basic 'flashed firmware not being set to boot' issue is real.

Note that I might be doing something horribly wrong and I previously used the Arduino core to work with ESP32s, not the IDF or Rust.

Partition table

# Name,   Type, SubType, Offset,   Size, Flags
# Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap
nvs,      data, nvs,     ,        0x6000,
otadata,  data, ota,     ,        0x2000,
phy_init, data, phy,     ,        0x1000,
ota_0,    app,  ota_0,   ,        0x1C0000,
ota_1,    app,  ota_1,   ,        0x1C0000,

[bugadani]

First up, it's good to see that I'm not the only one who uses 2 OTA partitions without a factory app :)

Above is my best guess at what's going wrong.

I think your guess is correct and I've seen this behaviour with esp-idf as well. My usual workflow was a simple idf.py flash monitor which absolutely didn't touch otadata, which wasted quite a bit of my time trying to figure out why my newest firmware wasn't running.

I guess in the long run, espflash might support flashing to arbitrary partitions, but for now the simplest solution might be to nuke otadata when the firmware would be written to an ota partition.

[jessebraham]

Apologies for taking so long to get to this!

I believe you are correct that we are simply not setting the correct OTA partition as the boot partition; this step was not included in esptool.py, which is mostly what this project is based on, and is instead in otatool.py. I will try to get this resolved soon-ish.