Device OS changed on its own

A day or two ago I upgraded from OS version 0.5.4 to 0.8.0 RC11 on two Electrons. I experienced several problems with 0.8.0 so I decided to downgrade to the most recent official release version, 0.7.0; I did so yesterday. I woke up this morning, logged into the console and discovered that one of the Electrons was back to 0.8.0. Can anyone advise how that could have happened and why?

If you didn’t downgrade your user firmware to one that requires only 0.7.0, the device would upgrade itself back to a version compatible with the firmware you have installed.

If you have a product, if the default version or the current locked version requires 0.8.0, then that would cause an upgrade as well.

The device OS will never upgrade on its own; it’s triggered because the user firmware binary on the device requires an upgrade. Or a manual upgrade was done OTA by sending the system parts.

1 Like

Very interesting Rick, but that doesn’t seem to align with what happened.

I downgraded both boards to 0.7.0 via USB and then put them back into production. Both showed 0.7.0 in the Console. One of the two - the one responsible for transmitting a signal to the other every minute - would not send anything, even after waiting for 10 minutes or more (since I was no longer seeing ‘vitals’ I could not see the connection status or signal strength). I wondered if maybe the downgrade process somehow erased or otherwise affected the application firmware on the board, so I re-flashed the latter from the original file written by NCD that had been running successfully on 0.5.4 for a couple of weeks. Eventually, the transmissions resumed (the failure to do so earlier was probably due to failure to handshake with the cloud, which is a whole other problem that I’ll discuss later in another post).

As mentioned, both boards were running 0.7.0 when I retired last night. This AM, one is doing so still and one is back to 0.8.0. The one with 0.7.0 is running a different app, but one written at the same time as the other for 0.5.4.

BTW, note the battery state on the Electron running 0.8.0. It varies all over the place between 97% and 0% but there is no battery attached. Rather humorous but, of course, irrelevant.

Later today I will re-flash 0.7.0 and see if it “sticks” this time. I’ll report back here.

What Rick means is that the user firmware, not the device OS, is “targeted” for 0.8.0. When you compiled your code, you probably had one of the electrons selected as your target when it had 0.8.0 on it. So the device will automatically update the device OS to 0.8.0 to keep step with your user firmware.

So, what you will need to do is reflash 0.7.0 to the device, recompile your firmware to target 0.7.0, and flash your new firmware to the device again.

To do that, before you compile a new bin file, go to devices on the left and choose 0.7.0 from the “system firmware target”.



I suspect that that’s exactly what I did. Thanks for the clarification David. I’ll correct it tomorrow and let you know what happens. However, it turns out that the many problems I was having with 0.8.0 rc11 may have been addressed by the simple addition of the Li-Po battery (details if you want). It’s been running clean since noon. If it is still running perfectly by the AM, I may leave 0.8.0 in place.

If you’re using 0.8.0-rc and powering by VIN only (no battery) there is a bug where you need to call PMIC.disableCharging() from setup() and use SEMI_AUTOMATIC mode or the device won’t connect properly.

1 Like