System Firmware OTA


I’ve had a bit of a look on the forums but I can’t find an answer to this.
I’m a bit confused about the process of updating system firmware for multiple units. For example I’m about to ship some units to trial customers. I’d love to get 0.4.9 on them before they go, but if it’s not ready, is there an easy way to update this via OTA? Perhaps a similar feature as exists in the dashboard, but for system firmware instead of user firmware.
Obviously it would want to be a solution with ideally no input from the customer.

Feel like I might have missed something here but please let me know!

After some further reading, I see an auto update is planned :slight_smile: @Dave are you able to give any indication when this (and/or 0.4.9) might be ready? Cheers!

Once 0.4.9 is released, it will be auto-magically updated if you are using the latest option to compile.

Anyhow, if you compile against 0.4.9, the :cloud: will ensure that the device has the required system firmware by flashing it over to the device.

I’m not so sure if the product dashboard has this selection feature available though.

1 Like

Hi @G65434_2,

The firmware team has indicated to me they’re trying to ship the next firmware release as soon as possible, hopefully later this week but it’s hard to say.

At the moment you should be able to achieve automatic-updates by simply flashing an app complied with a later version of system firmware. When the device comes online in safe mode, it should receive updates automatically (unless its an electron).


1 Like

Great, thanks for that Dave. If I understand correctly, the difference with 0.4.9 will be that the user doesn’t have to manually put the device in safe mode first?

Hi @G65434_2,

The firmware has had safe mode for a while now (since the summer / fall 2015), so I’m not aware of a significant change to that process with this upcoming release. I hope that helps! :slight_smile:


Sorry, I know about safe mode, was more confused about your comment ‘when the device comes online in safe mode’. Does that the mean the user has to reset the device to get it into safe mode for the update to be applied?

Hi @G65434_2,

If the app you’ve flashed is built against a newer version of system firmware than what is present on your device, the device will startup in safe mode automatically. Is that what you mean?


1 Like

Cool I understand now, thanks!

1 Like

Another question along these lines a few months later. We are compiling locally, and currently on 0.4.9 firmware. Some of our devices show up on the dashboard with 0.4.7 firmware from a previous build. Since we have a released version of our firmware on the dashboard that is compiled against 0.4.9, when these devices come online they get automatically updated to 0.4.9 (awesome auto-correcting feature!)

How can we access the specific git commit of the system firmware that the dashboard auto-system-firmware-update uses?

We want to make sure we’re locally compiling against this for any given release we make. We have been proceeding under the assumption that the most recent system firmware release for a given version number is the proper place for this (e.g. Is that a good assumption, or might the dashboard be serving up something different, e.g. a version containing hotfixes since the last official release.


The 0.4.9 release is the tag v0.4.9-rc.3 - you can see that in the github releases page -

Thanks for the quick response @mdma , does this confirm that the releases in the firmware repo (denoted in github by by the git tag) are what gets auto-updated when the dashboard OTA flash system decides that a given photon needs new system firmware?

ie, a photon on 0.4.7 needs to be updated to 0.4.9 -> it will definitely use the firmware given by this tag: v0.4.9-rc.3

and a photon on 0.4.9 that needs to be updated to 0.4.7 -> it will definitely use the firmware given by the tag v0.4.7 (


Yes, but the cloud doesn’t downgrade versions (not 0.4.9 -> 0.4.7)

oh! I was under the impression that the dashboard knew which system firmware version the uploaded firmware required and would make sure the photon had the correct system firmware (in either direction).

So, now I’m a bit confused. I can imagine a few different ways the system firmware OTA fix could work:

  1. (my original assumption, now known incorrect) there is some record in the .bin that let Particle determine on upload, which system firmware version the .bin was compiled against. When a photon shows up on the particle cloud with a given Product ID, the cloud attempts an OTA to the released (or if on the dashboard and locked, the locked version) firmware. If the system firmware does not match the system firmware required by the uploaded .bin, then first update the system firmware OTA to the proper version, then update the application (OTA).

based on what you said above, it’s either the case that
2) the dashboard does know the version of the system firmware that the .bin was compiled against, and it only updates a photon upward if the version on the photon doesn’t match (but what happens if the .bin was compiled against an old version and the photon is on a newer version of system firmware? I don’t think that we’re guaranteed that all system firmware is back compatible to applications compiled against old firmware, are we?)

  1. the dashboard just always updates to a latest released version of system firmware if the photon does not yet have it. In this case, if Particle updates the version of system firmware that is sent to all photons (ie you release v0.5.0, and our released firmware is compiled against 0.4.9, would all of our deployed devices potentially have the wrong system firmware?)

I’ve looked around the documentation and forums and didn’t find a definitive explanation of this anywhere, but will happily go read that if I just missed it. (CC @jeiden, since we’ve recently talking about dashboard stuff.)

It’s supposed to be backward compatible, unless your program relies on the presence of a bug and the fix breaks that.

AFAIK it will not update to the default firmware version but to the max target version you’ve ever OTA flashed that device with.
So if you have a 0.4.6 device and build and flash a sketch with target 0.4.7 then you’ll get an auto-update to 0.4.7 despite 0.4.9 currently being the default.
There is also a difference if you set target in Build for 0.4.9 or for Default (0.4.9).
While the former “fixes” that target to 0.4.9 till you decide to explicitly select new target, Default (0.4.9) will rather “float” up with the most recent version - then being default - e.g. Default (0.5.0). Consequently each time a new release gets promoted to be Default (x.y.z) and you afterwards build/flash without changing the target, your device will be pulled up to that automatically.

1 Like

Thanks @ScruffR, but I think you may be talking about compiling with the web IDE? We’re compiling locally (so the system firmware version is given by which branch of the spark firmware github repo we’ve got checked out), and then uploading the firmware to the particle dashboard as a binary (.bin) file. There’s no option in the dashboard to specify anything about system firmware.

The description of updating to the latest system firmware that has ever been on a device is helpful, because maybe some of that same logic is being used by the dashboard.

As for this:

That is also very helpful, and we are indeed in that situation with respect to 0.4.7. Our code compiled against 0.4.7 breaks on a photon loaded with system 0.4.9 firmware (due to a fix @mdma helped us with regarding system events before they were fully integrated), but knowing it’s supposed to be back compatible will let us be careful of that moving forward.

Oh, sorry - missed that :blush:
But yes, I’d say so. The version the bin was targeted at will be the indicator for the auto-update. If the currently presen system has a lower version number it will be pulled up to the required version, otherwise the current version will be kept (even if system > application).

1 Like

So you’re under the impression that the dashboard itself inspects the binary upon upload to get the system firmware version? That would be good.

Can anyone from particle confirm this and/or point me at a resource that gives a bit more info about the dashboard OTA process with respect to system firmware?

Thanks, all

I’d rather think the OTA endpoint would do that, not necessarily the dashboard.
But an official statement might correct me on any of the statememts above :flushed: :wink:

1 Like

Hey @dan,

You always ask such great questions! :laughing:

I can confirm that our back-end does identify the version of system firmware that the user app binary was compiled against – regardless if it was done in the IDE or compiled locally. When the firmware gets uploaded to the cloud via the dashboard, this information gets saved in our database.

I can also confirm that a mechanism called “Safe Mode Healer” will correct a device that receives a user application that was compiled against a newer system firmware than what the device is currently runs. When this type of OTA occurs, the device will go immediately go into Safe Mode.

When the device goes into Safe Mode, it will publish an event to the cloud signaling the state of the device. This is where Safe Mode Healer kicks in. The Particle cloud will identify what version of system firmware the device is currently running, check the requirements of the user app that was just flashed, and trigger an OTA of the required system parts to resolve the dependencies. This will happen in two consecutive OTA flashes (system part 1, system part 2). The device will then reset and begin running the new user app firmware.

This mechanism is true for devices that must update forward in system modules. That is, if the device is running 0.4.6 system modules and receives a binary compiled against 0.4.9, Safe Mode Healer will trigger an OTA of 0.4.9 system modules for that device. However, this mechanism is not required for devices receiving a user app compiled against an older system firmware than the user app. As mentioned, this is because system modules are backwards-compatible.

Hope this helps fill the gap!