Re: Saving data in CPU on-chip EEPROM

On Fri, 17 Jun 2005 09:30:29 +0200, David Brown
<david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

>Anton Erasmus wrote:
>> On Fri, 17 Jun 2005 07:27:03 +1200, Jim Granville
>> <no.spam@xxxxxxxxxxxxxxxxx> wrote:
>>
>>
>>>Anton Erasmus wrote:
>>>
>>>>>One solution may be to use checksum on all block of data, and
>>>>>always recalculate the new checksum after each parameter change.If
>>>>>the checksum is not OK I can clear all parameters.I don't like this
>>>>>solution because in case of one error I should clear all
>>>>>the list of failures.
>>>>>Is there any other solution or suggestion how to solve this problem?
>>>>
>>>>
>>>>Use Gray Code for the counters. Only one bit changes between succesive
>>>>counts, which of course means only one byte changes. Make sure that if
>>>>there is a power failure, you have enough power to at least complete
>>>>any write you are busy with. That way if power fails, you either have
>>>>incremented the counter, or you have missed only one count.
>>>
>>> Sounds fine, but what actually happens in the EEPROM update process,
>>>is the buried EE state engine first erases the byte (or page) and then
>>>replaces it with the new value(s).
>>> Some have Page schemes, but allow single byte replace - that just
>>>means they ready the page, XOR it with the new info, and write the whole
>>>page back.
>>> Thus, even with Gray code, there are finite times, where you have
>>>[OldValue][Erasing to 0FFH][0FFH][Writing NewValueZeroes][NewValue]
>>
>>
>> That is why I suggested that there must be enough capacitance to allow
>> any write that has started to complete. Many external brownout
>> detectors has a "power-fail" alarm pin that activates at a higher
>> voltage than the reset. This pin can be used to make sure that a write
>> is not started just before a power fail.
>>
>> [Snipped]
>>
>
>Gray code here provides no possible benefit, since the data is not
>updated a bit at a time. Gray code is important when sampling multi-bit
>data in different clock domains (such as for absolute position encoders,
>or counters in FIFOs), but gives you little (avoiding the occasional
>write of the high byte of your 16-bit counter) for the extra headaches
>here. If your power-fail alarm and your capacitor charges are
>sufficient to ensure that power-fail will never stop in the middle of a
>write, then just store the counters directly. Of course, it relying on
>such a system would be risky if it is not clearly over-dimensioned,
>especially when there are such simple ways of ensuring reliability
>without it.

I disagree. Using gray code when incrementing/decrementing a counter
in EEPROM ensures that one need to worry only about one byte at a
time. (Only one bit changing implies that only one byte changes) One
then only has to ensure that the EEPROM write is not started just
before a power fail, and if the power fails just after a write has
started, that there is enough reserve power for the one byte write to
finish. Using the appropriate external browout detector, makes this
simple and reliable.
One can also put the Gray count value in the EEPROM such that one
EEPROM byte represents a single bit. Again because only one bit
changes, one has to worry only about updating one byte per count.
Even if the underlying mechanism erases a page, and reprograms it,
there is still a maximum time that it takes to do this, and one must
just ensure that if a write has started, that the MCU stays alive for
this time before going down.

Regards
Anton Erasmus
.

Relevant Pages

  • Re: Saving data in CPU on-chip EEPROM
    ... Use Gray Code for the counters. ... Gray code is important when sampling multi-bit data in different clock domains (such as for absolute position encoders, or counters in FIFOs), but gives you little for the extra headaches here. ... One then only has to ensure that the EEPROM write is not started just before a power fail, and if the power fails just after a write has started, that there is enough reserve power for the one byte write to finish. ...
    (comp.arch.embedded)
  • Re: Saving data in CPU on-chip EEPROM
    ... >>If you can make your hardware safe for a single byte write, ... If you have lots of eeprom ... >For just a counter the gray code method is simple and easy to code as ...
    (comp.arch.embedded)
  • Re: Saving data in CPU on-chip EEPROM
    ... >>>to EEPROM, then other methods such as you describe are in order. ... >>>For just a counter the gray code method is simple and easy to code as ... I can't think off hand of a pattern that does this (or even ... it wasn't "perfect" in the sense of exactly distributing the ...
    (comp.arch.embedded)
  • Re: Saving data in CPU on-chip EEPROM
    ... If you have lots of eeprom space and want to spread your wear-and-tear evenly, that's perfectly possible too. ... For just a counter the gray code method is simple and easy to code as well as reliable. ... rotated one bit to the right (so that the LSB gets moved to ... In this rotated code, the frequencies are ...
    (comp.arch.embedded)
  • Re: Saving data in CPU on-chip EEPROM
    ... >[Regarding gray code] ... >> If only a single bit changes, it folows that only a single byte ... Hence to increment a counter one only has to write one byte ... >If all you ever need to save to EEPROM is counters, ...
    (comp.arch.embedded)