ESP32 Forum

Is it possible to use OTA with an ESP32c3 that has only 2MB of flash? I have seen partition tables where OTA1 and OTA2 seem to be the same address so is this possible on the understanding that if it failed, we're "in trouble"? Is there any recovery mechanism possible that does NOT require cables and flashing from a local system?

papadeltasierra wrote: ↑

Thu Dec 07, 2023 9:32 am

Is it possible to use OTA with an ESP32c3 that has only 2MB of flash? I have seen partition tables where OTA1 and OTA2 seem to be the same address so is this possible on the understanding that if it failed, we're "in trouble"? Is there any recovery mechanism possible that does NOT require cables and flashing from a local system?

I don't think that's realistically possible because
1) an application (or bootloader) cannot overwrite its own code while it is running (unless it runs completely from IRAM)
2) the bootloader could overwrite any application partition, but
3) if a bootloader were to use WiFi or Bluetooth for OTA, you'd end up with a ~1MB bootloader

Thinking about it, it may be possible to do a 'hybrid' OTA where the application retrieves the update data in compressed form and stores the compressed data to a flash partition, and the bootloader takes that data from flash, uncompresses it and updates the application on the next boot.
This may save a lot of flash memory because it doesn't require storing a full second copy of an application in flash, and 'only' the code for decompressing the update has to be added to the bootloader.
Edit: Ah, no, probably also not realistic as-is. The binary delta will need the full previous version of the application intact until completely 'decompressed'.

It all comes down to how large your typical application binary is. If you configure your build for minimal size (especially by disabling logging) then you can squeeze a lot into a ~1MB partition. For reference, the factory app on the device next to me with WiFi STA+AP, HTTP/S client and server, responsive web page, OTA uploads and downloads, and drivers for various things on the board comes in at about 650kB.

If you need a larger app partition, you could have a layout with a minimal factory app (like above) with the sole purpose of retrieving OTA updates, and a much larger "main" app. When an update is available, reboot into the factory app so that it can overwrite the main app partition.

MicroController wrote: ↑

Thu Dec 07, 2023 10:32 am

The binary delta will need the full previous version of the application intact until completely 'decompressed'.

Only if you go the delta path. A long time ago I implemented your exact idea, with the bootloader using the decompression functions in ROM so it was fairly lightweight. IIRC I abandoned it because the compression ratio was often so bad that the complexity didn't seem worth the hassle.

Thanks both for the interesting suggestions.

Quick addendum - it seems that the board I am using (a LilygoT-Zigbee) does have 4MB of flash for the ESP32c3. What confused me is that the default `esp-idf` configuration builds for 2MB and on boot reported flash reported is not the actual amount present, rather is is the build setting.
Changing the build setting was required to actually use the available 4MB!