ESP32 OTA Partition schemes: Arduino IDE

[andre_luis]

I would like to uderstand what is the actual memory space for the following scheme, more exactly, regarding to the only option with OTA.
The problem is that, even when we select a specific board, having known hardware specs ( Flash size, Osc Freq ), there appears the whole set.:

Nothing to complain, after all, that's a toy oriented platform.

So, once they mixed up manysizes in the partition scheme list, I need to confirm the one I tagged above, if it indeed corresponds to the 4M Flash.

Considering that the linker creates 2 partitions ( Ap0, Ap1 ) with the same size to deal with OTA ( current firmware, uploaded firmware ), I would bet the 1.9M there ( actual compiled: 1.966 M ) do refers to one of the partitions, therefore being this option related to any board with 4M Flash ( 1.966+1.966+0.19 ).

Any thoughts ?

 

[betwixt]

I use OTA on almost all my ESP32 designs, regardless of how much memory is available. The file sent OTA is normally compressed but obviously how much it compresses depends on its contents. The loader uncompresses it directly into application space.

I'm using a 4Mb WROOM module partitioned 1.2Mb APP/1.5Mb SPIFFS (the default for 4Mb) and loading a program that receives JSON encoded power usage data over WiFi and displays it on a graphical color LCD. uploading the program over USB so it shows statistics in the IDE tells me:
"Wrote 877824 bytes (562739 compressed) at 0x00010000 in 8.1 seconds (effective 866.2 kbit/s)"
if that helps. I use the Espressif "preferences" library for storing incoming data because it incorporates wear levelling, I'm almost certain it stores in the SPIFFS partition.

Brian.

 

[andre_luis]

I'm using a 4Mb WROOM module partitioned 1.2Mb APP/1.5Mb SPIFF

Something I forgot to mention is that as you I also use a significant amount of resources, but the size of my binary is currently 1.44M, which in this case, a partition like yours would not meet; the partition I have mentioned in other hand do meet, but my original concern was to know if they consider a duplicated section on that scheme: 1,9+1,9+0,19 (< 4) .

Then, even though the term 'OTA' is not explicitly mentioned in the title of the above Arduino scheme list, it would be compatible anyway, right? From what I read, when dealing with OTA, the core need to allocate each partition at specific sections of the memory, namely Ap0 and Ap1, that's why I thought there were strict conditions do work with this - I mean, if OTA was not explicitly stated, no OTA compatible.

BTW, have you already used ElegantOTA library?
People praise this one a lot.

The file sent OTA is normally compressed but obviously how much it compresses depends on its contents. The loader uncompresses it directly into application space.

My biggest concern is the system's ability to recover, rolling back to the original firmware in case of upload problem, and even though the data is compressed during the upload, if there is no redundancy of the currrent version+updated version, this will be an issue.

if that helps. I use the Espressif "preferences" library for storing incoming data because it incorporates wear levelling, I'm almost certain it stores in the SPIFFS partition.

I'm confused: Are you using another approach, such as a self made OTA-based bootloader? The question arises because when dealing with these libraries I don't care of the nuances of how it was implemented in the guts, at the most just configuring the allocation for each partition.

I also make use of the 'preferences' library, but only to store regular data.