Remote Firmware Upgrade for Electron

I tried to update the firmware on my deployed Electrons today. Specifically to go from 0.6.2 to 0.7.3rc6.

I looked at the documentation and decided to try the command line interface. I was able to flash each of the three parts of the new firmware (last part console dialog posted below):

cmcclell-OSX:Downloads chipmc$ particle flash Umstead-Graylyn system-part3-0.7.0-rc.6-electron.bin 

! Flashing firmware Over The Air (OTA) uses cellular data, which may cause you to incur usage charges.
! This flash is estimated to use at least 0.139 MB, but may use more depending on network conditions.

! Please type 0.139 below to confirm you wish to proceed with the OTA flash.
! Any other input will cancel.
? Confirm the amount of data usage in MB: 0.139
attempting to flash firmware to your device Umstead-Graylyn
Flash device OK:  Update started

After this, I thought I would check the firmware status in the IDE and, to my surprise, it was still at 0.6.2. Is there some limitation on this update process or reason why I would not see any error message on the command line but still not successfully change the firmware version? I have looked at the other threads on this topic but, did not see a clear answer to this question.



1 Like

So these are not listed as a Product?

I know @Vitesze had a similar issue where the Electron would keep trying to update the firmware because the server didn’t see that the new firmware version had taken when it actually did.

He added a 5-second delay before calling before going into deep sleep to fix his problem which I didn’t think was needed but it worked for him. Maybe he will chime in here.


I have not yet taken the plunge to group my electrons into products. Is that a requirement for this to work?

If you have gone down the product road, how was it?



I have not had the need to do this yet but I’ve been following @Vitesze as he now has 50+ units online and is working through all the issues.

He saw the same issue of the console not showing the correct firmware version unless he added that delay before calling Cellularoff(); but that should not be needed although it fixed his issue so I figured I would mention it.

I’d trust the CLI over the indication of the web IDE. Place the device in listening mode, and issue ‘particle identify’ to see what’s actually on the device.

1 Like


Thanks but, these devices are remote so I only have the CLI. Also, when I compiled and deployed the sketch, it would only work at 0.6.2 so I think the device is at that release.


Can you tell by your data usage if it sent the update or not?

Fyi, adding a 5-second delay before calling Cellular.Off() doesn’t force the handshake for me,but fixed another issue that I had (regarding rebooting the device and Cellular.ready() being stuck in FALSE)

For the record, the issue @RWB is referring to is related to Particle Cloud being very picky with when it makes a handshake - without this handshake, the firmware of devices shown in the Cloud won’t be updated (although the firmware download itself may have been successful). This firmware mismatch between Cloud and device led to my Electrons re-downloading the same firmware continuously. This is still preliminary, but the following code snippet posted by @ScruffR appears to have fixed this for me:

void dummy(const char* filter, const char* data) {

void setup() {
Particle.subscribe(String(, dummy, MY_DEVICES);

1 Like

There was some issue in the past where the new system version was only reported after flashing some “old” version application code to the device - while at it, make sure the newly flashed application has a different set of Particle.function(), Particle.variable() and/or Particle.subscribe() references to force a handshake.

One other thing to consider is that 0.7.0-rc.6 (and previous RCs) also comes with a new bootloader try flashing that too.

And for safety I’d always first test these kind of things with a local device :wink:

1 Like


OK, I am finally able to take a look at this thread and give it a short. As you prudently advised, I will first attempt this with a local device. I have some questions on this whole firmware update thing so, please indulge me or point me to the docs / threads where I can get smart.

  1. Bootloader. You mentioned that 0.7.0rc6 comes with a new boot loader and I can see it is there with the system images. However, when I follow the documentation for updating to this release, there is no mention of updating the boot loader. Am I missing something here or does installing the three system image parts also take care of the boot loader. Also, I can see the firmware release I am on in the IDE, do I also have to worry about the boot loader?

  2. Different techniques for updating. Particle offers a number of different approaches - Firmware manager (does not work for release candidates), Web IDE (does not update the firmware and puts device into “safe mode”), Command Line DFU. Only the last method works for me. Is there a best choice here or should stick to CLI since it can handle remote as well as local over USB?

  3. How do I make sense of the various releases? Correct me if I am wrong but, there is a production release at 0.6, six release candidates for 0.7 and, before a production release of 0.7 is out, there is already a release candidate of 0.8. Is there a roadmap or decision tree here which could answer some basic questions and help me decide which to use? For example, will there ever be a production release of 0.7 or will it skip to 0.8? For an Electron on a tight power budget, is 0.8 a big enough change (noticed power management in the features doc) to warrant the risk. I know there is a Firmware update thread but it has gotten very long. I realize there is also a Firmware Update comments thread but, it does not seem to be very active. I was hoping for a roadmap or guidance doc that was more net and was focused on the current release options.

Thanks again for your help and apologize if these questions are too basic.

Any reason you’re not trying out updates via the Particle Product update method?

It’s free at the lower number of units you have but I’m guessing you may want to avoid the cost down the road once you get into the quantity that requires a monthly fee?


To be honest, I have no problem paying for the functionality. I had heard that the project method is complex but, if that is the answer then I am happy to take a look. Thought I should be able to follow one of the non-product methods first though.


  1. IIRC the system parts don’t contain the bootloader but somehow an update should manage to upgrade that too.
    But since I don’t quite know what this somehow does I just apply the bootloader manually too - you may call it superstition :wink:
    However, if you want to upload the bootloader you’d need to do it via Listening Mode and particle flash --serial <bootloader.bin>.

But if an application update triggers an OTA system update (e.g. Photon or Electron product) then the bootloader is definetly applied OTA too.

  1. Firmware manager seems to be dead. Since 0.6.0 there was no update for it, so there is no use in applying it IMO.
    Web IDE does trigger Safe Mode Healer (auto-update) for Photons but not for Electrons due to data consumption considerations.
    CLI is the Swiss Army Knife for Particle devices, so it’s always best to have it handy.
    However Particle Product service is an option and not that complicated - as long as you are your own customer :wink:

  2. 0.6.4 is the most current official release but 0.7.0 will not take too long before becoming the version to go to. 0.7.0-rc.6 is pretty much in lock down for release and I wouldn’t be surprised if there were 0.7.x sub-releases before 0.8.0 will become an official release version. There are numerous features and issue-fixes milestoned for 0.8.0 which will require some to mature d get thoroughly tested.
    So for a production unit 0.7.0-rc.6 (which will most likely be 0.7.0) might be a rather safe bet and if there are any critical fixes in 0.8.0-rc.x Particle will most likely backport them as they have done with some security patches (like KRACK WPA2) even for 0.5.5.