They need to handle failures including partial and unverifiable uploads, and maybe invalid signatures, definitely do when it comes to CRA.I think that OTA Updates need to use Flash partitions with a recovery mechanism in case of failure/partial updates.
Burning to flash should never happen until a complete, correct and verified upload has been staged and is ready for burning IMO, but it could be possible to create a chunk-by-chunk update mechanism.
Using partitions isn't necessary IMO, and needing partitions is not necessarily desirable. Not least because RP2040 and Pico W don't support partitions and I believe those deserve being able to support OTA and even CRA updates. But I have no objection to partitions being used for RP235X. Partitions may not be that useful if one wants to update more than half the Flash where some chunk-by-chunk update would need to be used.
There are two options for recovery - Allowing recovery, but that may require having to hold three copies of an image at a time which means having larger Flash and a mechanism to handle all that. Or no recovery, basically keep trying to update until it succeeds. Not so bad if what's to be burned has been staged but potentially problematic in other cases.
There's also a choice to be made when it comes to protecting the code which does the upload, whether that's protected by software or is locked in Flash. There are pro's and con's to both.
Most makers and hobbyists will simply want to build as they always do, then transfer their code by OTA, not jump through hoops to make things OTA capable, so how that is handled is another issue.
There's a whole range of possibilities and I am also interested in how it may apply to OTA updates of MicroPython firmware and user programs.
I am looking forward to seeing what emerges as examples.
Statistics: Posted by hippy — Thu Mar 20, 2025 5:35 pm