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

Not too worried about radiation, but more in the domain of bad code.

I normally leave the EEprom address pointer sitting at 0x0000 when exiting
a read or a write.
On writes I read first, if the data is already there, then I'm done.
The multiple bytes/xor idea hopes to detect a reboot or power fail during
write by having the three important bytes disagree in that case.


On Fri, Dec 6, 2024 at 7: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
>
-- 
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
https://mailman.mit.edu/mailman/listinfo/piclist