More on update
"Between stages, the board will appear functional while the next group of updates is downloaded, but during the update you should expect the board to be unresponsive for several minutes at a time."
I guess we'd better not install it in anything critical then, like a lift (elevator) or an HVAC controller.
User enters lift, presses button, doors close, lift ascends, software update. "Several minutes" later the panicking user is rescued by fire crew.
HVAC reaches low-level set point, turns on heating, software update... several minutes later the humans expire from heat stroke.
At the very least, we need to be able to specify a time to check for update. It seems to me that there is a small team, dedicated to fixing / implementing OS functionality, but there's no-one looking at the bigger picture. Embedded devices are not PCs, they MUST work 24/7 , work mostly / sometimes-connected, be able to deal with sudden, dirty power removal. Has anyone tried pulling the plug in mid-update?
In our 19.09 release, we have enabled the ability for an application to defer an update (In critical scenarios for instance).
You can learn more on this feature at https://docs.microsoft.com/en-us/azure-sphere/app-development/device-update-deferral
A sample code is provided on GitHub at https://github.com/Azure/azure-sphere-samples/tree/master/Samples/DeferredUpdate
Aaron Smith commented
Just got a board today and was absolutely shocked to see that it auto updated and was unresponsive while doing so.
This CANNOT HAPPEN with an IoT device. Until this is rectified, this is a no go for any commercial application and will strictly be a hobbyist/toy project.