OTA which survives power failure

[plerup]

Maybe I'm missing something but I looks to me like if we have a power failure during the OTA update in eboot.c (ACTION_COPY_RAW) we end up with a non functional system.

Couldn't the data structure "eboot_command" be stored in flash instead and not be reset until ACTION_COPY_RAW operation has been successfully completed?

BR
/Peter

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[igrr]

It's certainly possible to pass bootloader arguments via flash. This will require allocating an additional sector for eboot_command (like it is done in other bootloaders).
By the way, another point of failure is when the actual image is written. If the power goes out between the moment when the first sector (which contains the bootloader itself) is erased and when it is written, system will not boot.

[plerup]

Couldn't we have (optional) skip of updating the bootloader sector?

[igrr]

Sure, such option may be implemented in Updater class.

[plerup]

I could give this a try. Just not sure how to allocate the extra sector though. Never touched base with the linker before... Have to explore a bit first.

[igrr]

The tricky part is to allocate this sector when users asks for it, so that flash space is not wasted by default. This could be an additional option in Tools menu or something like that.

[plerup]

Maybe optionally using the last 128 bytes in the EEPROM sector

[me-no-dev]

I'm thinking of something else... since there are sectors at particular locations that are used by the SDK to store settings and such, maybe we can use those? They are a full 4K blocks but data in them is usually not more than 128B, so using the end of one of them can maybe give you the space for storing that data and not mess with EEPROM or the linkers.

[davisonja]

I'm a big fan of updates that survive power-failures (in as much as they don't render the device unusable).
I've got a revision of master that stores a command in flash, falling back to RTC if there's no valid flash block available, or there's no command (so we gracefully fall back to current behaviour).

Aesthetically I like the idea of stealing a 4k page at the start of flash - so eboot and its config are all kept together. On a module with 4M this is no real issue, but I realise that this is more of a concern in smaller ones so it does really need to be optional.
Having an optional page at the start makes life more complicated, so for dev I've opted to use a page at the end, modifying the .ld file(s) to reduce the SPIFFS space by 4k. While this works relatively nicely, there appears to be some use of the space at the end of flash - does anyone have a pointer to concrete documentation on which pages are used?
I'm reluctant to hijack parts of pages in case their usage changes in the future, and I've not explored the possibility of storing the data in SPIFFS itself (on the basis that a solution which doesn't require SPIFFS is a better place to start).

Does anyone have any thoughts/ideas on a suitable flash location? Because reducing SPIFFS_END resulted in a page that was overwritten, I'm wondering if shifting the start of SPIFFS is more reliable.

As a side note I'm looking at allocating a full 4k with a view to storing general update config there as well, particularly a key for firmware signing/encryption.