Retained Variables may get reset on firmware update

[twospoons]

This one caught me out, but its clear why if you think about it for a moment. If the new firmware has the same variables in the same order as the previous firmware, it looks like retained variables survive the firmware update. Altering the variables results in re-initialisation of retained variables, as everything has moved about in memory.

It would be nice if we could specify RAM addresses for retained variables, so they (might) survive a firmware update. EEPROM is an alternative, but not for something that gets rewritten constantly. And since System.updatesPending() isn’t working properly at this time, there’s no way to store vars in EEPROM just before an update.

Worth noting in the documentation.

[kennethlimcp]

@twospoons

System.updatesPending()

I recall someone reporting issues with this recently; not sure if it's you.

I used it in a recent project to shut down the lights and motor if there is a firmware update and it worked fine.

Can you elaborate more on the issue you are facing?

[twospoons]

Check this thread:

How to notify application incase of an incoming OTA update?

Hello, I need to notify my Photon incase of an incoming OTA update. My Photon does something critical for 15 secs(not to be interrupted). If there is an OTA update issued within that 15 seconds a flag should be raised to perform the OTA update after the Photon completes it’s critical task(after 15 seconds). I used the API’s listed in here for this purpose. I did the following: Disabled the OTA updates using System.disableUpdates() Checked pending OTA updates using System.updatesPending() Bas…