Re: [EE] High reliability store and recall of data in EEPROM

I am going to append this to my original response (if all I have is a
hammer everything looks like a nail). I'd be happy to be educated about
better ways.

If I had to implement it in C or assembly, I might be tempted to regard
math intensive self correcting codes/routines with suspicion.

Three independent copies of data (with CRCs or whatnot, possibly in three
different eeproms?). In the event of a single changed byte, two values will
match and one will mismatch, one can rewrite the third with the correct
value. And if all three mismatch, fail as safely as possible.

It's an easy scheme to analyze and test for correctness.

On Fri, Dec 6, 2024 at 9:04 PM David Robertson <[email protected]> wrote:

> I think you need to consider the causes of data corruption.
>
> If you are only concerned about the values in EEPROM spontaneously changing
> (e.g. due to the effects of cosmic radiation or degradation over time) then
> a CRC or your XOR scheme will help.
>
> But probably there are other scenarios you care about, like power loss (or
> other interruption) happening during writes. Then you will need to consider
> what happens if the write is interrupted at every possible point in the
> program execution. Especially if you are saving a change to multiple
> variables/bytes in one go and expect that change to behave atomically. It
> can be challenging to get it right. Often append-only log data structures
> are used.
>
>
> David
>
>
>
>
>
>
>
> On Fri, 6 Dec 2024, 17:24 Jason White, <[email protected]>
> wrote:
>
> > Consider using an 8-bit CRC three or four times in a row.
> > One byte of the original value,
> > byte two is your CRC function called on the value once in a row
> > byte three is your CRC function called on the value twice in a row
> > byte four is your CRC function called on the value thrice in a row
> >
> > On Fri, Dec 6, 2024 at 4:51 PM David VanHorn <[email protected]>
> wrote:
> >
> > > I have a need to store some data in non-volatile memory, with the
> caveat
> > > that corrupt data MUST NOT occur.  Things go "big badda boom"
> otherwise.
> > >
> > > Offhand, I came up with storing each byte as a four byte array (I have
> > TONS
> > > of space available)
> > > If I'm storing 0x01 then it would look like this:
> > >
> > > 1       2        3       4
> > > 0x01, 0xFE, 0x01, 0x55
> > >
> > > Xor 1 and 2, result must be zero.
> > > Xor 3 and 2, result must be zero.
> > > compare 1 and 3 result must be zero (not sure this is needed)
> > > check 4, must be 0x55 otherwise a wild write has happened in EE.
> > > Finally the values allowed will be sparse, and likely only a single bit
> > > will be set, so I will check that the value I read is one of the
> > allowable
> > > values.
> > >
> > > If any of those checks fails, we render safe and halt.
> > >
> > > Is there a more "rock solid" method?    What would be done in an
> > automotive
> > > environment for something like throttle position?   What would be best
> > > practice for medical life safety?
> > > --
> > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > > View/change your membership options at
> > > https://mailman.mit.edu/mailman/listinfo/piclist
> > >
> >
> >
> > --
> > Jason White
> > --
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > https://mailman.mit.edu/mailman/listinfo/piclist
> >
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> https://mailman.mit.edu/mailman/listinfo/piclist
>


-- 
Jason White
-- 
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
https://mailman.mit.edu/mailman/listinfo/piclist