Electron Firmware and Dev

[stofmike]

Hi

So as I understand the Particle Dev compiling against the latest released firmware. But I may have a different firmware version on devices in the field - in particular electrons. If this firmware which is compiled against the latest version is flashed to a device with a previous version it goes into safe mode.

This is not ideal when devices are in the field. What is the proper process to ensure this does not happen. I know there are updaters which require a usb connection or you can used the web IDE but I want to know if/ how this can be achieved though Particle Dev without the device next to me

Cheers
Michael

[Moors7]

At the moment, there currently isn’t a way to do this using Dev, unfortunately. That should change with the upcoming work on the IDEs. For the time being, you could develop in Dev, but then compile/flash using the CLI if you prefer a more local approach.

[stofmike]

Thanks Moors, always quick to respond. I had a look around and found the below in another thread. it says the device will autoupdate - which I am not seeing and from your response you also don't think so. Do you know what the below is about then

jeidenParticle Sr. Software EngineerApr 18
Hey @dan,

You always ask such great questions!

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!

Jeff

System Firmware OTA

Hello 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 ideall…

[ScruffR]

Auto-update (respectively Safe Mode Healer) is disabled for cellular devices to prevent unexpected excessive data usage.
It’s only there by default for WiFi devices.

But as @Moors7 said, build with CLI

particle compile electron . --target 0.5.3 --saveTo firmware_electron_0.5.3.bin

(supposing you’ve got 0.5.3 on your device and you execute the command from your project folder)

And Safe Mode ensures that you can still flash OTA even after you tried to flash incompatible firmware before and now want to flash a compatible firmware.

[Moors7]

I guess I misunderstood. Safe Mode healer should kick in if flashing user firmware > system firmware, as far as I’m aware. It will indeed go into Safe Mode, which should then cause it to auto-update. Does it not upgrade when you leave it be for a bit (the system firmwares take a bit more time than the user firmware)?

My reference to “this is not possible” was in regards to selecting a ‘lower’ system version using Dev, as to circumvent the need to update altogether.

[ScruffR]

As said: SMH won’t do that for Electrons.

[stofmike]

Hi

Thanks. I appreciate using the CLI I can compile for the version on the Electron. But how do I update the firmware version to a newer one. So, as an example I have 0.5.3 and I now what to use some functionality in 0.6.0 and at the same time update the firmware. How do I enable self mode healer to perform the update?

Also, it seems risky to use the particle Dev to compile as a new version of firmware may come out which it will compile against and causes issues in the field

[ScruffR]

With 0.5.3 and later OTA firmware update should be possible via CLI

particle flash <deviceName> system_part1.bin
particle flash <deviceName> system_part2.bin
particle flash <deviceName> system_part3.bin
particle flash <deviceName> yourFirmware.bin

The binaries can be downloaded from GitHub (and always sent out in the Firmware Update Thread )

@stofmike

Also, it seems risky to use the particle Dev to compile as a new version of firmware may come out which it will compile against and causes issues in the field

Not really

@ScruffR

Safe Mode ensures that you can still flash OTA even after you tried to flash incompatible firmware before and now want to flash a compatible firmware.

[stofmike]

Thanks, this is helpful

My point about it is risky is that when the device is in safe mode it is not doing what it should - I appreciate that safemode means you can flash again but until you determine there is an issue the device isn’t doing what it should.

[ScruffR]

@stofmike

My point about it is risky is that when the device is in safe mode it is not doing what it should

Yes, but is flashing a wrong firmware (which was the case here) the actual risk here?
If you flashed a compatible binary that's just not doing what you want it to do it's just as "dangerous", or not?

If you have mission critical devices, you should be testing on your bench first and only deploy when done and dusted.

With Safe Mode you even get an Event that's actively informing you about the fact, which would not be the case if you just flash compatible code.
So this behaviour seems even safer.
Another point in that respect is, that blowing through your data quota with unexpected system updates might not only be the extra cost, but the fact that you might exceede your hard data limit which will deactivate your SIM for that month, which may be happening delayed to the "offending" reason of the unexpected update.
You flash incompatible code, SMH kicks in and updates and you check your device which is now running without issue, but two weeks later (when you are on holiday) the quata runs out and your device will be offline till you come back.

[stofmike]

Thanks - you are correct on the flash first on a bench.

With regard to data - this may be true for the particle sim card where data is expensive but the 3rd party sims we use costs around 16c a MB and we are moving over to ones where it costs significantly lower than that. At present some of our devices are using 15MB a month - a few firmware upgrades do not concern me. But I recognise that is that the case with all.

Your point on auto updates is taken. It would be nice to choose to update, I suspect that will come in time

• The Web IDE doesn’t give you a good way to manage code files but you can choose the firmware version to build against
• The Dev environment gives you a much better way to manage files but always builds against the latest version
• So, in my case the best option is to use the Dev environment and compile through the CLI

You guys have been very helpful, thanks