EEPROM: managing address mapping between firmware versions

Question

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?

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.

2. 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.