-->
Page 4 of 4

Re: Example of featured sketch wanted

PostPosted: Fri Oct 12, 2018 3:54 pm
by btidey
OTA needs twice as much flash as the size of the program image. It is saved to flash during the OTA operation but not on top of the previous image which is still running during OTA.

So a 410K image needs a 1MB flash assuming SPIFFS is not using flash. With larger flash you can choose how much to allocate to program and how much to SPIFFS. So a 4MB could be allocated at 1MB program and 3MB SPIFFS. A 2/2 or 3/1 split allow for larger program images with OTA although maximum image size is 1M anyway.

Re: Example of featured sketch wanted

PostPosted: Sat Oct 13, 2018 1:55 am
by grhhm
martinayotte wrote:it is burned on the flash while binary stream comes in, chunk after chunk ...

Awesome!
So if final checksum is wrong or network transmission interrupted then the ESP is bricked instantly. Correct?

Re: Example of featured sketch wanted

PostPosted: Sat Oct 13, 2018 3:35 am
by btidey
The standard OTA splits the flash into 2 areas. The new firmware into loads into a different area of the flash from the existing sketch so that is not replaced until the OTA successfully completes.

Theoretically a different OTA mechanism could use a small separate download piece of code and overwrite the original main firmware on the fly. This would avoid the need for twice as much flash, but might carry the risk of a bad upload being more difficult to recover from. Given that a lot of modules have 4MB Flash it is better to have the existing more secure OTA mechanism.

Re: Example of featured sketch wanted

PostPosted: Sat Oct 13, 2018 5:53 am
by grhhm
Thank you btidey.
Double bank firmware management makes a lot of sense. It's reasonable tradeoff between required space and reliability.