Is there a common way to handle changes in the mapping between eeprom addresses and variables between firmware versions? It's not about the eeprom memory to survive the update, but to be(come) compatible with future sketches with a possibly different set of variables.

To make it clearer consider the following fictional scenario:

A coffee machine has been programmed to measure water_temperature and the firmware is supposed to stop heating within a temperature_hysteresis below set_temperature. set_temperature is a persistent parameter that has been individually optimized be the user and must therefore survive any firmware update. As a configuration parameter also temperature_hysteresis is stored in the eeprom. Now the manufacturer decides to update his machine with a PID-controller, making the parameter temperature_hysteresis obsolete while he introduces some new parameters for the controller's gains (pid_gains). How can he manage that the firmware keeps values that haven't been touched by the update (like set_temperature) while the additional parameter pid_gains is added.

I assume that obsolete parameters should be removed as there could be more updates with new parameters in the future. That's why simply incrementing the eeprom address and ignoring deprecated addresses probably won't work.

On the other hand, when re-using old addresses I wonder how a fragmentation of the eeprom can be avoided. I came up with the idea of putting all configuration data into a json in the eeprom and to handle the problem a layer above by parsing the json for configuration data. But anyhow, that feels so wrong and might be too complicate.

Does anyone have experience with this kind of problem and knows how this routine is commonly implemented?

1 Answer 1


There's lots of ways you could handle this.

Two thoughts right off the top of my head:

  1. Have a "Version" identifier in the EEPROM.

The firmware then needs to know the EEPROM layout of all versions up to the current one. It can then read the EEPROM from the old version and write back a new format for the current version.

  1. Have each entry in the EEPROM tagged with a "meaning".

This is not too different to your JSON idea (which you are right is horrible), but instead of lots of words you just use a simple number to identify the meaning of the value it is associated with. Assuming that each stored value is an 8-bit byte (though it doesn't have to be), you could allocate "1" as "set_temperature", "2" as "temperature_hysteresis", "3" as "pid_gains", etc, Then the EEPROM might contain the bytes 1,96,2,5 and the firmware would know that the second byte is the set_temperature because it has a 1 in the first byte.

You can think of it as a "key / value" pair, but both the key and the value are just numbers.

To find the temperature_hysteresis you just scan through all the even EEPROM entries until you find 2, then read the next entry. If you don't find a 2 then you use the default value.

Your firmware can then choose to either update an existing cell that is tagged with the right type (scan for type, update next cell), or it could erase all the values and replace them with just the ones it cares about - the choice is yours.

Any values that your firmware no longer cares about will be ignored, and potentially erased.

  • Thanks for your immediate answer! I don't know if I have fully undestood your first solution, but it sounds like I could still run out of memory after a limited number of updates. But the idea is to do all previous changes in eeprom mapping one after another until the latest version (in case that one has missed some updates in the meantime), isn't it?
    – Sim Son
    Commented Sep 14, 2019 at 0:06
  • your second solution is quite clear in general, but I wonder how to handle datatypes of different size. Do I have to store the size of each value after its "key"-byte or how would you do that?
    – Sim Son
    Commented Sep 14, 2019 at 0:11
  • You could infer the data type from the key.
    – Majenko
    Commented Sep 14, 2019 at 0:19
  • Yes, wrapping a routine around it to achieve this is another story, but at least that's no mystery to me. Thx
    – Sim Son
    Commented Sep 14, 2019 at 0:25
  • I also have things like look-up tables (not entirely predictable size/structure) that need to be stored. What are the disadvantages of using my json approach in spiffs? I mean, it's in the flash anyway...
    – Sim Son
    Commented Sep 14, 2019 at 0:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.