Hello,
I am working on a project which requires the use of non-volatile memory (flash) to store information such an API key, and wanted to incorporate some form of redundancy in case the data in flash becomes corrupted. My plan was to store the key, and redundant copy of the key, as well as the crc of the key.
For the sake of example:
Bytes Use
0-3 CRC
4-35 Key (primary)
32-63 Key (redundant)
My main question is, would this actually be doing me any good, or just needlessly complicate my code? I'm sure many people here are familiar with the idea of cosmic radiation potentially hitting the flash chip and changing data (transient errors). Is it possible for a single bit to flip in such a scenario, or is it more likely to affect a larger range since the redundant data resides in the same location as the primary data?
I am thinking that I might be better off keeping a redundant copy somewhere else, such as a filesystem via SD card, as that may potentially be "disjointed" from the primary data location in flash, therefore more suitable as a redundancy.
I'm sure many people here are familiar with the idea of cosmic radiation potentially hitting the flash chip and changing data (transient errors).
Flash memory is not EEPROM memory.
I'm not sure cosmic ray-effects (at terrestrial altitudes) affect anything other than DRAM, of which there there is none in a typical Arduino system
TheMemberFormerlyKnownAsAWOL:
Flash memory is not EEPROM memory.
I'm not sure cosmic ray-effects (at terrestrial altitudes) affect anything other than DRAM, of which there there is none in a typical Arduino system
Sorry EEPROM was a misnomer and I forgot to clarify in my original post, but I am working with a device which only contains flash so the "EEPROM" is simply emulated in the flash chip. That is interesting though, I assumed any form of storage/memory was susceptible to the issue, thanks. Will need to do some research regarding soft errors in flash.
srnet:
Whilst its possible that 'cosmic rays' will corrupt an EEPROM, I would suggest that is a very remote possibility at ground level.
If this key is important, then keeping it in one place, on one component, is daft.
Your device could suffer; component failure, theft, fire, flood or whatever, which no amount of clever coding will protect against.
Does your sentiment not also apply to keeping the program in one place, on one component? As far as those other scenarios which were listed, I don't really see how any those are relevant to the question.
flonch:
Sorry EEPROM was a misnomer and I forgot to clarify in my original post, but I am working with a device which only contains flash so the "EEPROM" is simply emulated in the flash chip.
You're using an ESP8266?
Still not a serious issue. Flash is pretty darn stable.
Does your sentiment not also apply to keeping the program in one place, on one component? As far as those other scenarios which were listed, I don't really see how any those are relevant to the question.
That's why normally the program is kept (in source code) on a separate computer, typically the one used to program it on. That of course allows for additional local backups, and upload to version control systems such as Github, both of which are recommended. It is indeed far more likely to lose data to events like device failure than corruption of single bits by e.g. cosmic rays.
Don't store just one copy of the CRC. If that gets corrupted then both copies of the data would fail the CRC check. Keep a CRC with each copy. The one that passes the CRC check is the good one.
Or keep three copies of the data and the two that agree are the good ones. Majority rules. If you test each bit separately you can recover from many single-bit failures, as long as the same bit is not flipped in two copies. Add a CRC to protect against having two failures on the same bit on different copies.