Comments on: Keeping your EEPROM data valid through firmware updates

By: Nigel Jones

Nigel Jones — Thu, 28 Jan 2010 12:04:20 +0000

Ashleigh:I agree with you about the checksums. I'll point out that I did say in the post that I was ignoring issues related to corruption – which is the principal job of the checksum.I don't agree with you concerning loading default values. I've designed products where effectively halting and doing nothing is far worse than loading default values and proceeding. I do agree that it is essential that the user be informed that default values have been loaded.

By: Nigel Jones

Nigel Jones — Thu, 28 Jan 2010 11:58:38 +0000

John:The downgrade problem is indeed an interesting problem – and certainly one that I can't address adequately in the comments section. I'll endeavor to put together a blog posting on this in the near future.

By: ashleigh

ashleigh — Tue, 26 Jan 2010 02:09:05 +0000

Another couple of suggestions:1. Add a signature to the configuration block, before the version information. The signature should be AT LEAST 32 bits, in which you store a unique code per product (keep a company wide register of signautures used). Common geeky examples are 0xFEEDBEEF, or 0xABADBABE. Then you compare the signature present against the signature expected to see if the config block is even present.2. Checksum the configuration as the last step of loading a new one – but only if the configuration is totally static and treated by the program as read-only. Store the checksum after the version, make sure its set to 0 during the load and calculate and set it when load is complete. On start up, check the checksum.3. Never ever ever ever automatically detect bad configuration data and auto-regenerate it. I've had a case where a former employee did this, and dodginess in the design led to about 1 in 100 cases where at power up all the settings got blown out and re-created with defaults. If defaults are to be loaded, it must always be by an explicit action – preferably in the factory.

By: John

John — Mon, 25 Jan 2010 16:27:56 +0000

I came across your column via a reference from Michael Barr of Netrino. He sparked my attention by his comment "Fellow EmbeddedGurus blogger Nigel Jones is obsessed with writing efficient C code. He experiments with alternative coding constructs, carefully examining the compiler's output for each, when normal people are sleeping." I thought I was the only one who experiments with the output of various 'C' constructs every time I use a new compiler (or version) to determine which generate more efficient code.At my company we have been using EEPROM versioning similar to your suggestion for years. It works very well except for the problem of customers who insist on flashing backwards to old versions of code. Our only solution to this has been to clear EEPROM and set all values to default if an unknown version is found. This of course has it's problems. So many that it took management approval to make a version change. As such we have finally resorted to clearing all EEPROM settings on manufacturing and never changing previous locations only adding new ones. Any new values added are designed so the cleared value is either the default setting or an invalid one. This enables us to tell if the location has ever been set.Do you have any ways to handle this?