OTA update of system firmware - Photon

Hi All,

I have to update a number of units I have in the field to a new version of the system firmware. Everything I have read indicates that I need to put the device in safe mode prior to sending the OTA update commands to the Particle cloud. Here is the problem the instructions I have seen instruct setting safe mode via the 2 buttons. This is not possible for me, I need to do this update remotely without and onsite person involved in addition to the fact that the 2 buttons are not user accessible on our device.

Has anyone run into this? Is it possible to solve this by maybe uploading tinker first then sending the OTA commands without safe mode?

Please let me know how you did it if you had a similar situation.

So has any

Hi @HardWater,

If your app doesn’t block the cloud connection, you should be able to do an OTA system update without going into safe mode. You can optionally put the device into safe mode over the air by sending your new app using the latest system firmware (046, etc). Then you can send part1 / part2 manually over the air. We usually recommend safe mode because there are fewer things that might prevent the upgrade from succeeding.

I hope that helps!
Thanks,
David

Thanks @dave,

Yeah I would love to go with stock firmware but there are a couple of mods we have implemented at the system level that is keeping us from running stock code so I need to push the updates myself.

I am guessing that the following would be a safe approach to OTA updates.

  1. Flash tinker that was compiled with the old system
  2. Flash the new system part 1
  3. Flash the new system part 2
  4. Flash the new user code that was compiled with the new system

Do you agree that seems correct?

1 Like

Hi @HardWater,

That sounds fine, just about any combination of those works so long as part1 goes out before part2. :slight_smile:

Thanks!
David

1 Like

Hey @Dave,

I have been thinking about this further. One concern I have had is that sometimes when I send an OTA update of user code though I get a successful response from the particle cloud in actually the update does not get installed and it reverts to the old version. This is okay in that I pass a sw_rev with my code to my server. All I need to do it try again.

My concern is in this process of OTA flashing of part 1 & 2. Is there a rock solid method of insuring that each part of the process is successful before moving of to the next.

My question is very similair to the one @enjrolas asked at Determining the version of system firmware on a Photon/P1 but noone replied.

Hi @HardWater,

Good question! The cloud is generally reporting that the OTA update started successfully, instead of blocking until the full transfer has completed. There are a few ways we can address this that I think would help.

  • introducing an api option when flashing to block until the transfer succeeds successfully
  • have the cloud publish an event after the device reconnects positively confirming that a new module or app was installed or not.
  • a new opt-in feature we’re building that detects when a device is in safe mode, and attempts to apply upgrades to the device until it’s out of safe mode.

Would those help?

Thanks!
David

1 Like

I think any or all of these would be helpful, since it’s probably a very common issue to not know exactly what version of the firmware you’re building against (especially with Particle Dev), and mismatches are bound to happen when a new firmware version is published.

3 Likes

I totally agree with that. A nice thing to have would be to be able to setup the firmware version in Particle Dev the same way we do it in Particle Build. I wasted days last week trying to use interruptions, until I realized my photon was not running the firmware I thought it was… it doesn’t make so much sense to have to use Particle Build when we want to change the version, and then switch to Dev because it’s the one we use more often… All the more with the fact Build uses folders (for libs) and Dev can’t… An homogeneous dev environment where code works the same on both IDE would be great by the way… :wink:

3 Likes

Regarding monitoring an OTA update of the firmware for a photon which is on the other side of the planet, embedded in a 3-d model, strapped to a buoy in the Atlantic, etc. – in other words, you can’t see it. I have noticed and can replicate the following: if the photon is in safe mode (and assumedly blinking magenta) it is reported as online via particle list. Here is how you know when the firmware update is complete.

While the OTA firmware is flashing, the photon will appear as offline. When the first part of the system update is done (system-part1.bin), the photon reconnects and shows up again as online. Then go ahead and flash system-part2.bin, again, the photon appears as offline via the CLI during the OTA flash, when complete, it reappears as online.

Now, what would be neat is if the CLI would report back during a particle list and say, hey, Photon online safe-mode. There’s a request. :wink:

3 Likes

Hi @Dave,

The following option looks most useful, as it makes automating the whole process that much easier.

From my perspective, what I most want to be able to do is push out an upgrade (which may include non-stock system firmware if we need to put fixes in there), and know that it has succeeded, or not. But, simply blocking or raising an event is not quite enough as there are holes e.g. if there is a loss of connectivity between our backend and your cloud. A more robust solution would also allow us to query the cloud for the versions of the various components installed on a device (i.e. it'll tell us which versions are actually installed), and in addition to providing an event, provide an indication as to whether the latest upgrade attempt was successful or not.

Dunk

1 Like

The way I ended up partially solving this problem is I did a binary compare of my old part 1 & new part 1 to find the first memory location that is different between the old and new I also did the same for part 2. I send these values to my server as part of my normal communication. This way I can spot devices that do not have the correct part 1 or part 2. As it regards the response from the particle server when I get the Update started reply I find 90% of the time the update is successful it is the 10% that causes me a lot of aggravation.

Hi @Dave & @jonlogan ,

Hey I am having a problem with getting some of the units I have in the field to take the OTA update of the system part1. I have been able to OTA update my user code and system part2 but when I execute the flash command for part1 it does not seem to complete even though I get
{“id”:"----------------------------------",“status”:“Update started”} back as a response from the server.

Keep in mind that the OTA update for some other customers of these 3 pieces works fine. My thinking is it has something to do with the file sizes the part1 is 244K part2 is 161K & my user code is 21K.

Any idea what it could be? If I pm you the device ids is it possible that you could look into this in detail?

Hi @HardWater,

Sure, feel free to ping us with deviceIDs, we can also turn on advanced logs for your devices which might help provide more insight. Does flashing work when the device is in safe mode?

Thanks!
David