Retained variables are reset after adding a new one

Firmware
,
#1

Greetings. The reference for P1 says the following:

“When adding new retained variables to an existing set of retained variables, it’s a good idea to add them after the existing variables. this ensures the existing retained data is still valid even with the new code.”

But after the next OTA update, only one variable was preserved. I added the retained variable to the end of the variable list. As stated in the reference, I did not use structures.

You can see the code for variables before and after OTA.

If I don’t add a new retained variable, then everything is retained. I cannot use magic bytes, since the backend does not save these variables I have nowhere to restore them. Thinking to use EEPROM before flashing. But first I want to know what my mistake is here.

Also there is a question: if i create backup retained variables, and then rename them, will they change during OTA update?

#2

It’s virtually impossible to guarantee that retained variables will retain their values across firmware recompiles. It usually works, but there’s more variability than the documentation would lead to you to believe and that should be documented. This is especially true if the Device OS version changes or the compiler version changes (as was the case in 2.0.0).

The best odds of retaining the values correctly would be to use a single retained struct. And only one in the entire application, so reordering won’t happen.

2 Likes
#3

Thanks for the answer!
I have used one retained struct before. One in the entire application. But when adding a new variable to the structure, erasures also occurred. I was looking at the addresses of the memory cells where the variables were stored, and for some reason the two variables had the same location. I thought it was because of the structure and redid everything into a list.
What about saving to EEPROM before flashing? Is this solution better?
So far, I think the best solution is to organize the storage of data on the backend.

#4

EEPROM is much safer, as you manually control the address within the virtual EEPROM and the compiler never reorders the contents randomly.

1 Like