The scenario is I have a struct containing parameters that is stored in EEPROM - I have added a new parameter ( bool type) to the end of the existing structure and then I flash the application to the device. I want the parameter to be set to true immediately after the first flash but thereafter the parameter should be retained from whatever it was set to true or false. Can anyone suggest a foolproof way to do this? I have tried testing for 0xFF but this value isn’t always present in the bool parameter after flash.
I usually add a magic number and a checksum to my EEPROM stored structs. When changing the layout of the structure or adding fields I mutate the magic number and of course the checksum would then need to account for the extra space taken too.
In case you want multiple generations of your struct to be valid, you could keep previous magic numbers and checksum algorithms in your code and pick the fitting combo depending on the stored magic number.
1 Like
The CRC for sure is required for integrity, but in addition to the magic numbers I would add a byte for version and another one for type, if the storage cost is of no concern.
Keep the the same pair of magic number to say “Hey, I may have some valid data here” followed by a header with version+type of data, then data and finish it with your CRC.
If you plan to transmit this data in the future you want to calculate the CRC from header to the end of data, since the magic numbers is just part of your storage schema.
1 Like
Another approach - I have a simple parameter struct (name[8], and value[20]) and I use
To manage a set of records of this struct. (simple dB) in the EEPROM. I also write a magic number to top or bottom of EEPROM - so now you can extend the “db” with new version of your app easily. I do a magic number check on startup, if incorrect re-init the “db” to known defaults (including new records) and then use data as needed. Currently my one project has 39 configuration records that are updated from the central backend as needed. Can share if needed?
Thanks all for ideas share - I need to understand the operation of this so @shanevanj your Arduino database library is a useful. I have not implemented CRC checksum thus far and wonder how necessary this is a solution to an issue that occurs how often with eeprom? Or am I mis-understanding the checksum use i.e. it is for total size change? In which case storing a size byte at the start of the struct and checking for a change would be sufficient with perhaps a version number to allow for specific upgrade handling?
The algorithm can be quite simple and while it ensures data integrity any change in size would also refelct in a mismatch of the stored and recalculated checksum.
While adding a size field should be enough for your needs the extra "cost" for data integrity would be marginal and hence I'd consider it worth the few extra code lines.
1 Like
Normally the problem is not how often it happen, but when it does, how do you know what happened? CRC algorithms are standard and a simple one can help you. If you chose to use one, remember to add event/log when you have a CRC error, it will help you a lot debugging possible problems.