But nowhere in any of these can I see the OTA size being explicitly called out. The flash layout page notes that the OTA area immediately follows the program (sketch) section, but I can’t see a way in the ldscripts to do exactly what I want.
I’m on a 1m device, and I’d like to partition Flash as follows:
My reason for making the OTA smaller than the flash is because I am using gzip to compress the .bin file before upload, and I typically see a reduction to between 75% and 70% of the original .bin filesize. Therefore setting the OTA size to a little over 80% the Sketch size seems like the optimal solution.
The thread above mentions an OTA size of 470K, but the only guess I can come up with is that the sketch memory is simply split 50/50 between actual storage for the sketch and OTA storage. In the absence of gzip, this decision makes sense, but since the Arduino core bootloader provides gzip support, it seems like it would be a good idea to use it.
It’s been a few years since I worked with an ESP 1M.
As far as I understand it: The ESP8266 does not have an OTA partition!
OTA Updates are written at the end of the Sketch partition.
This is also illustrated here:
|--------------|-------|---------------|--|--|--|--|--|
^ ^ ^ ^ ^
Sketch OTA update File system EEPROM WiFi config (SDK)
The OTA sketch is first written to the end of the sketch partition. If this was successful, the OTA sketch is copied to the beginning of the partition.
For this reason, the sketch partition must be twice as large as the actual sketch itself.
Therefore your approach (GZIP upload) will not work.
I had a similar problem back then and solved it with two OTA sketches.
The production sketch (larger than half of the partition, not able to load a full new OTA image)
A minimal OTA sketch which only contains OTA code and waits for an OTA upload.
The OTA sketch was very small and therefore still fit into the partition of the normal sketch.
The procedure was to upload the minimal OTA sketch first and then the production sketch.
This worked perfectly.
That’s interesting. I’d read this section regarding compression of the OTA bin file (actually bin.gz): OTA Updates — ESP8266 Arduino Core 3.1.2-21-ga348833 documentation (arduino-esp8266.readthedocs.io)
and the impression I got was that the eboot loader does gzip decompression on the fly as it’s reading the OTA image and writing it to the flash. If this is true, the total sketch space only needs to be the sum of the decompressed sketch size and the compressed “OTA size”.
I’ve posted asking about this on the Arduino Forums. They’re the people that wrote the OTA library I’m using, and the documentation I’m referring to, so I figure they ought to know.
If if does turn out that compressing the OTA doesn’t reduce the flash requirement, then your “two-step” approach is definitely a good trick to remember if my sketch does get too large.
Hi sivar2311,
Neat trick, splitting the OTA and production images.
How would your system recover from OTA image update ‘killing’ the previous OTA image? How would you have updated/recovered after that?
Regards
The production sketch must of course also have OTA implemented.
That makes sense, I suppose.
Depending on the size of an actual ‘production’ image, however - it might at some point make also sense to have two partitions for the classical A-B update and switching between them (since we already have 2x OTA image).
How small was actualy the OTA image in your case (comparing to your typical production image)? It should have had an HTTP client and some TLS at least, right? In that case - certificates somewhere too?
Sorry, if the question is too self explanatory. I have unfortunately never worked with ESP OTA/Arduino OTA sketch myself.
All I can recommend today: switch to an ESP32.
The ESP8266 is discontinued and the ESP32 has all you need and more RAM / Flash and of course power. It also support a factory app beside the ota1 and ota2 sketch.