ESP32 Forum

I have noticed when I run make flash, the output shows the image was compressed. Is there anyway to access the compressed image for OTA?

Hi embedded_systems,

Yes! esptool.py can compress the image when it goes over the serial link to reduce the number of transferred bytes. It's decompressed when written to flash.

You can absolutely do something similar when sending the image over the air. The IDF "OTA" support deals with the on-device aspects of the OTA update (writing to flash, changing the currently selected app, etc). The network layer is more or less up to you.

There is an OTA example in IDF that uses a very basic HTTP transfer, but we'd encourage production use to use a different protocol (HTTPS or something else). You could use HTTP/S's gzip compression feature or something else to reduce the transfer size.

The ESP32 ROM actually includes a copy of the "miniz" gzip library that can be called from IDF apps: https://github.com/espressif/esp-idf/bl ... om/miniz.h

(Regarding the network layer and the OTA example, we have plans to roll out an IDF HTTP/S client library and also some more comprehensive production-ready examples of "higher level" functionality like OTA. I don't have an ETA for these right now.)

ESP_Angus,

I currently have in place a way to transfer the image over the air from my secure server. Everything works great. My image is over 1M so I want compress it so I don't have to alter the standard OTA partition table. Do I have to decompress it once I've saved it to the OTA_1/OTA_2 memory location? Or do I decompress each chunk of data that comes over? Or can the esp32 use the compressed image, thus requiring less space for the application image.

You have to decompress it before you write to the ota partition. So you won't save any flash space. Most of the image is code that executes from flash through cache so it has to be in uncompressed format. I suppose the ram sections could be stored compressed if the bootloader was modified to decompress them but it probably be a modest gain.

What WiFive says is 100% correct.