I think your version _is_ the simplest thing that works: software updates are part of what needs to work in embedded. else you brick devices and have to send technicians to the device, right?
The simplest thing that would've worked was for the initial firmware to do nothing besides putting the new firmware in the secondary slot, tell mcuboot to upgrade and then reboot. That shifts the responsibility of working upgrades to later firmware revisions, at the cost of significant technical debt and extra development costs in the future.
My point is that the simplest thing that could possibly work disregards state and time as factors. Good engineers balance all requirements to derive the simplest solution that works; great engineers do so while avoiding visits from irate future colleagues.
having created a dependable a/b update for firmware (with failure detection and fallback), I can confirm this alone is a very very tricky challenge.
and I can confirm the good / great threshold.
my point is that given a high enough cost of "brick over the air", anything below great is not enough. think automotive, or any other industry where you need to send out field technicians to the bricked devices to fix the problem.
If it's affordable to ask a customer to put in say a USB stick into some specific slot and to download things themselves over the Internet, then the simplest thing that possibly works may not need the same complexity, I agree.
hehe, thank you for helping me getting this sorted in my brain. I have a strong tendency for making my problems even harder than they need to be. maybe this is exactly the point I'm at the: first figure how simple the problem is, before finding a fantastic solution for a problem that is more complex than reality requires.
