Does the OS update take precedence over other code being run? And does it wipe the nv table? I had some remote devices logging data to nv off-line, and the data was downloaded infrequently when wifi was available. However, recent connection causes the OS update and it seems the data was wiped before it could be downloaded. Just wanted to confirm the priority of the OS upgrade, and if correct, I’ll try and work out a way to avoid this happening during future updates.
Yes.
Have attempted a product as described, where it was confirmed that it can not be controlled in Squirrel (imp002 based). I believe something is planned in the future.
Also an issue for applications not using the nv table, as OS updates “strikes at random” seen from a squirrel perspective, and in some applications this can be experienced as a service disruption by end users.
When providing a service, where you even have to alert end customers when data uploads are lost, it is an undesirable behaviour.
To be fair OS updates happens rarely, and apart from the aspect here, this has been an extremely stable platform in the field (imp002).
Probably not a quick fix as the device can not be allowed to dodge OS updates all together.
We’re working on some new functionality that will make OS updates less intrusive: Squirrel will be notified of the update and will be able to opt to delay it until it has, for example, saved state information.
I believe today’s deploy fixes the problem which @jamesb notes - ie that if you connect and send data immediately, it will arrive with the agent even if the server then forces an upgrade. You must not idle before sending the data, though.
Up until today’s deploy, if an OS update was pending for a device, any data it sent upon connection was discarded and not sent to the agent.
We are working on a polite system for both Squirrel and OS updates as @smittytone says, which allows much more control for the application.
Thanks for the updates. I’ve now had quite a few devices on remote farms (quite a few kms!) that have gone offline, I’m pretty sure due to this. I’ve had to travel to them, power cycle, and “[Exit Code] imp OS upgraded” is what appears in the log first when I power cycle. Bit of an issue for my use case - maybe partly due to the devices using deep sleep modes, or sometimes having poor internet access due to location.
Being able to control when this happens would be very useful. Especially seeing as it’s hard to work out how to make the device respond more gracefully when this happens, since I can’t trigger an imp OS upgrade on the bench myself.
So, you definitely shouldn’t have had to power cycle anything; I’d appreciate a bit more info on any devices you had to do this on. Before release 32 there certainly were some corner cases where things could go wrong & a power cycle would help, but any device upgrading recently would have already been on 32 so has the updated upgrader.
Does the OS upgrade process pull all GPIOs to ‘0’? I’ve got one of the GPIOs controlling a power supply for the cellular->wifi modem (with a pull-up resistor). If the OS upgrade pulls the pin to 0, it will suddenly lose access to the internet. Could that be the cause? I also had some settings for connection in the nv table, so if the table was being emptied, it might have taken devices offline. I’m working on making that more robust now.
Any time your squirrel isn’t running (imp asleep, during a squirrel update, during an OS update) all the GPIOs are tristated.
Your pullup would ensure that the pin stayed high.
Hi Hugo. What should one assume happens straight after an impOS upgrade? Will it be exactly like a cold boot (nv table empty, begin executing code from the top)?
Yes, aside from the wakereason will indicate an OS update.