Re: EEPROM guarantees after power loss during a write
- From: John Devereux <jdREMOVE@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 07 Feb 2008 11:25:05 +0000
ssubbarayan <ssubba@xxxxxxxxx> writes:
On Feb 6, 5:25 pm, John Devereux <jdREM...@xxxxxxxxxxxxxxxxxx> wrote:
[...]
This is equivalent to what I was planning. Although I don't think I
need a checksum. I was going to have "valid" markers, separate from
the data blocks. So it would go
mark copy 1 invalid
write new copy 1
mark copy 1 valid
mark copy 2 invalid
write new copy 2
mark copy 2 valid
On power up both copy valid flags would be checked, and any "invalid"
copy overwritten with the valid one. The "copy valid" markers would be
stored on separate pages from the data (and each other), so hopefully
will not get corrupted at the same time as the data they refer to.
Only problem with this is it requires 4 pages to be written instead of
one. Using a checksum to replace the separate flags could mean just
two pages - perhaps that is better after all.
[...]
Hi John,
I will continue using brackets while posting long links.
They have to be *angle* brackets, < >. But you are using google
groups, which usually scrambles everything up anyway.
By the way,I have a question regarding your implementation.
In your algorithm to make two copies of any data in nvram,what if
during updation to both the copies you encounter power brownout?Since
power brown outs are unpredictable,how are we going to guarentee
atleast one good copy exists with us?
The scenerio which I am referring to here would be the first time when
you are updating the data.During first updation,you wont be able to
ascertain whether the copy is good or bad.
Another question is at what point of time you would update the
validity flag for the data?
update():
a) mark copy 1 invalid
b) write new copy 1
c) mark copy 1 valid
[same again for copy 2]
startup():
any copy marked invalid is replaced by the copy marked valid.
The steps happen in strict order. Each previous step must complete
successfully before the next is started. So the only way the valid
flag can be set is if the data has been successfuly written, without
interruption.
On what basis you would come to know data is valid given that you dont
have a checksum?
The data is marked valid only *after* it has been successfully
written. If writing of data is interrupted, then the flag never set
either. So next time it powers up we know that copy may be bad, and
restore from the good one.
There is always at least one good copy.
Let us look at what happens if programming is interrupted during a,b,d
above.
a) The copy 1 valid *flag* is left in an unknown state. But the actual
data is valid. So either the startup will see it invalid and restore
the data, or it sees it valid and all is OK.
b) The data is marked invalid, and the *data* is left in an unknown
state. This is OK, the startup will see the invalid flag and restore
the data.
c) The data has been correctly written, but the valid flag is left in
an unknown state. If the startup sees the flag as valid, that is OK,
because the data is in fact valid. If it sees it as invalid, the data
will be restored from the other copy. Still OK.
Obviously this make a few assumptions: the eeprom has not worn out,
and that there is some brownout protection so that the CPU does not go
crazy and erase everything.
Another assumption is that the flags are either programmed or not
programmed. But what if the flag programming gets interrupted so that
the flag state is not only unknown, but is actually *unreliable*. That
is, it is only "half programmed" (or half erased), so sometimes reads
"valid" and sometimes "invalid"? In this condition the state read
could depend on temperature,age or supply noise.
It would require a very unlikely sequence of events, but you could
have:
update()
...
mark copy 2 invalid
write copy 2
mark copy 2 valid <interrupted>
Then on power up, copy 2 valid flag is unreliable. But at startup
happens to read OK.
Then next time we do an update, we get *another* power cut, this time
during copy 1 update. And at power up, this time copy 2 reads
*invalid*. So we have no valid copies.
I think the solution is to reprogram the "valid" flags every startup.
I am sorry if these questions look amature,I am trying to understand
it and felt your algorithm is more simpler then mine except for extra
memory needed for having copies.
I find it a difficult area, too. (And it gets harder if you start
thinking about wear-levelling or if you don't want to allocate a whole
page to a record, or if the record does not fit in a single page...)
Looking farward for your reply and advanced thanks,
Regards,
s.subbarayan
--
John Devereux
.
- Follow-Ups:
- Re: EEPROM guarantees after power loss during a write
- From: ssubbarayan
- Re: EEPROM guarantees after power loss during a write
- From: David Brown
- Re: EEPROM guarantees after power loss during a write
- References:
- EEPROM guarantees after power loss during a write
- From: John Devereux
- Re: EEPROM guarantees after power loss during a write
- From: ssubbarayan
- Re: EEPROM guarantees after power loss during a write
- From: John Devereux
- Re: EEPROM guarantees after power loss during a write
- From: ssubbarayan
- EEPROM guarantees after power loss during a write
- Prev by Date: Ribbon cable
- Next by Date: Microchip MPLAB IDE Selecting Device
- Previous by thread: Re: EEPROM guarantees after power loss during a write
- Next by thread: Re: EEPROM guarantees after power loss during a write
- Index(es):
Relevant Pages
|
Loading
