Is it possible to update my devices in the field to 1.0.0 without reflashing user firmware?
I don’t think so. First, firmware is compiled against a specific target. Even if you could, something may break, especially with a major change.
In Web IDE you can’t simply upgrade the device OS. Neither in a product situation for an OTA flash.
Why would you avoid reflashing user firmware?
3 Likes
Every iteration of my firmware is different, due to potential of publish and subscribe overlaps. It would be almost impossible for me to keep copies of every device going out. And if I want to upgrade a device to 1.0.0 for diagnostic purposes, its very hard to.
Yes you can update device OS only OTA.
You'd use particel flash <deviceName> <firmware.bin> for OTA updates for system binaries just the same as for application binaries.
But there are no guarantees that your firmware would still run after that, especially when there is a change in the major part of the version number, since that may also indicate breaking changes.
How many fundamentally different applications are you running?
Also what if a device for some reason just quits working, would you just dump the entire project since you don't have the code for it anymore? Seems risky 
2 Likes
The fundamental differences are small. But at the beginning of my project I didn’t keep up with a lot of the publish and subscribe names, so if I want to update now it makes it very difficult to Flash OTA.
And how about gradually re-unifying your individual products?
Also if the differences only are in the pub/sub names having these parameterised and stored in EEPROM via a setup function might be an option too.
A major version change may be the perfect reason and time to do that.
3 Likes
What are the benefits of having that stored in the eeprom? I’m not against it, I’m just curious as to what the reasoning behind it is.
That you can change them without the need for a firmware update.
e.g. this would be a non-issue if you had them dynamic
4 Likes
What are the benefits of having that stored in the eeprom?
As a practical example @Mjones I use to be in a similar situation and now better understand your objective. I used to use hard coding radio addresses and flashing to devices. But with a firmware upgrade, or improvement to application code, I had to remember to re-flash each device with the correct code base for its set of radio addresses.
Now I store those radio addresses in EEPROM, and I can update OS and application code and in the code read from EEPROM the values specific to that device.
3 Likes
That’s exactly what I’m having to do. Looks like I’m going to be learning how to program this into eeprom.
I haven’t fully executed on this, but something else to consider in your situation. Also add a hardware revision number in eeprom so you can maintain a single code base for diverse devices, where later versions may have additional sensors, etc. Then the code can add logic based on hardware version whether to or how to use changed hardware functionality.