Firmware upgrade process

I’m sure there are things in place but just wanted to check if there is any chance of devices getting partially updated firmware? e.g. power goes down half way through upgrade. I assume you do some sort of checksum of the actual data transferred down, so that should be safe. But what happens if it’s interrupted in the unpacking stage/writing stage.

Just wanted to know the worst possible scenario :slight_smile:


The impOS upgrade process is failsafe as we have both an impROM (OS image) and a bootROM (recovery image). So if at any point during the OS upgrade we lose power or connection the imp will resume the upgrade the next time it is able to connect. We’ve done a ton of work to make the upgrades as fast and seamless as possible. The last round of upgrades from release 30 to 32 was still using older bootROMs and there were some performance issues. With release 32 (the current release) we also updated the bootROM (again, in a failsafe way) so upgrades should be much faster and more reliable now.

If you’re asking about the Squirrel firmware. I’m not sure if we keep two copies of the Squirrel firmware (I think it depends on the size) but, again, if an update is interrupted the imp will download the new Squirrel the next time it connects.

Good to know thanks.


I record the bootROM of all of our dev devices and I see that they report around 4-5 different versions. Will they be consolidated to a single version at some stage?

Can you share what versions you are seeing? (I’ll take user data any chance we can get it)

There are a couple versions on 32.* bootROMs since there we releases of 32 which did not require a bootrom change. So, for example, if a device upgraded both the impROM and bootRom to 32.7, then a week later was told to upgrade to 32.12 only the impROM would update since there were no changes between the 32.7 and 32.12 bootROMs. If another device was powered off and missed the upgrade to 32.7 then came online to 32.12 it would have a 32.12 bootROM and impROM.

This is just an artifact of how we do software revision control so I don’t know of any plans to consolidate as it has no actual impact on the functioning of the imp or upgrade process (you’d literally be doing an update just to change a version number).

Sure, here’s a json list of 5 of the first 6 I checked: There is some variability in the bootROM (deviceROM), but less so with the impOS (deviceOS). These are not a cross section of our field devices. They are mainly some of our older imp001 devices. I think the imp002s may be more homogeneous. I can probe more of them if you need it.

[ { "deviceConnectTime": 1446786716, "sync": true, "timeoutLimit": 20, "agentUptime": 486357, "agent": true, "version": "1.12-2015/10/30", "deviceUptime": 486357, "device": true, "deviceDisconnectTime": 1446786716, "agentOS": "a86d9f7 - jenkins-ei-release-5291 - Sun Nov 1 04:40:57 2015", "serial": "237a414dead3dbee", "deviceAvailability": 1, "country": "00005355", "agentConnectTime": 1446786716, "deviceROM": "2ad6509 - release-32.11 - Fri Jul 10 13:28:22 2015", "deviceOS": "e1c04a0 - release-32.13 - Fri Aug 21 09:21:28 2015", "deviceDisconnectReason": "" }, { "deviceConnectTime": 1447268791, "sync": true, "timeoutLimit": 20, "agentUptime": 796547, "agent": true, "version": "1.12-2015/10/30", "deviceUptime": 796513, "device": true, "deviceDisconnectTime": 1447268791, "agentOS": "a86d9f7 - jenkins-ei-release-5291 - Sun Nov 1 04:40:57 2015", "serial": "233eafb030728cee", "deviceAvailability": 0.999957, "country": "00005355", "agentConnectTime": 1446480592, "deviceROM": "bf69322 - release-32.4 - Fri Apr 17 19:36:55 2015", "deviceOS": "e1c04a0 - release-32.13 - Fri Aug 21 09:21:28 2015", "deviceDisconnectReason": "" }, { "deviceConnectTime": 1446741856, "sync": true, "timeoutLimit": 23, "agentUptime": 796595, "agent": true, "version": "1.12-2015/10/30", "deviceUptime": 796555, "device": true, "deviceDisconnectTime": 1446741856, "agentOS": "a86d9f7 - jenkins-ei-release-5291 - Sun Nov 1 04:40:57 2015", "serial": "23535a4cead3dbee", "deviceAvailability": 0.99995, "country": "00005355", "agentConnectTime": 1446480616, "deviceROM": "205371c - release-32.6 - Wed Apr 29 23:03:03 2015", "deviceOS": "e1c04a0 - release-32.13 - Fri Aug 21 09:21:28 2015", "deviceDisconnectReason": "" }, { "deviceConnectTime": 1447271902, "sync": true, "timeoutLimit": 21, "agentUptime": 796618, "agent": true, "version": "1.12-2015/10/30", "deviceUptime": 779523, "device": true, "deviceDisconnectTime": 1447271887, "agentOS": "a86d9f7 - jenkins-ei-release-5291 - Sun Nov 1 04:40:57 2015", "serial": "23266ceb6e4936ee", "deviceAvailability": 0.978541, "country": "00005355", "agentConnectTime": 1446480628, "deviceROM": "d7fb311 - release-32.10 - Tue Jun 16 11:12:52 2015", "deviceOS": "e1c04a0 - release-32.13 - Fri Aug 21 09:21:28 2015", "deviceDisconnectReason": "" }, { "deviceConnectTime": 1447277203, "sync": true, "timeoutLimit": 20, "agentUptime": 796778, "agent": true, "version": "1.12-2015/10/30", "deviceUptime": 784703, "device": true, "deviceDisconnectTime": 1447277199, "agentOS": "a86d9f7 - jenkins-ei-release-5291 - Sun Nov 1 04:40:57 2015", "serial": "20000c2a69051c67", "deviceAvailability": 0.984845, "country": "00004247", "agentConnectTime": 1446480621, "deviceROM": "78f540f - release-32.12 - Thu Jul 16 09:55:33 2015", "deviceOS": "78f540f - release-32.12 - Thu Jul 16 09:55:33 2015", "deviceDisconnectReason": "" } ]

You have mixed versions as you were doing quite a lot of pre-release 32 testing on these units back earlier in the year, and you got the bootrom from the time of the upgrade (apart from when you were helping us with that post-upgrade delay issue, when you got forced bootrom updates from time to time).

We don’t currently force bootrom upgrades if you’re already on 32.x as there’s little effective difference, but I can tidy these up if you’d like. It’ll cause them to be offline for ~10 seconds - is that ok?

Yes, please. A good opportunity to test how the units recover.

Ok, all updated; a couple of them took ~40s to upgrade, the others were more like 8s. Are they in different places?

Thanks, I see that 5 units have updated. They are all local. After a restart, some of them probably took up to 30 seconds to connect. This is something we’ve observed many times. It may be ISP or router related. We certainly see it in our office regularly.