Re: EEPROM guarantees after power loss during a write



On Feb 6, 5:25 pm, John Devereux <jdREM...@xxxxxxxxxxxxxxxxxx> wrote:
ssubbarayan <ssu...@xxxxxxxxx> writes:
On Feb 5, 11:28 pm, John Devereux <jdREM...@xxxxxxxxxxxxxxxxxx> wrote:
Hi,

I am wondering what guarantees are there for existing EEPROM data,
after power is lost during a write operation?

I am writing a datalogging routine that writes records to an
EEPROM. It's an Atmel 24C1024, although the question is probably
applicable to other devices too. This uses "page mode" for writes -
the device seems to be organised as 256 byte pages.

Say power is lost during a write to a single byte in a page. What can
I assume? Is just that byte suspect, or the whole page (or the whole
device)?

The microcontroller has brownout protection, so isn't going to run
wild - but what about the EEPROM internal state machine? Are they
generally protected against brownout?

If I write a single byte, does this in fact involve a hidden
erase/write of the whole page?

I can't find any information on this stuff.

--

John Devereux

John,
We encountered the same problem with our product(still
encountering...!).Even though we did not have a right fix,the way we
approached to provide a work around for this:
We implemented a checksum in our software to detect data corruption in
eeprom and incase we find corruption,have a known good copy of eeprom
data backup in ROM.(external flash).This data would be copied back to
the eeprom during bootup.So this ensures customer has good data when
he bootsup.
When wrong data is updated due to brownouts,checksum is prone to vary.
We will backup good data during a situation where we conclude at least
one known set of good data is there.(This can be ascertained again by
comparing with known checksum).

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.

We have used this workaround and after this workaround was
implemented,we never faced any problems with the content of
eeprom.Even though brownout situation still continues to happen,the
impact was greatly minimised.
As far this brownout,like your situation we also did not have either
an external capacitor or an brownout protection pin in our board.We
use ST's eeprom.I have raised a similar query to this a couple of
months bak.Given below is the link:
1)http://groups.google.co.in/group/comp.arch.embedded/browse_thread/thr....

I will look at these.

By the way, long links often get scrambled up on usenet. You can make
it easier for some people if you enclose in angle brackets

<http://groups.google.co.in/group/comp.arch.embedded/browse_thread/thr...>

This seems to stop them getting split up by news readers.

2)Regarding checksum:http://groups.google.co.in/group/
comp.arch.embedded/browse_thread/thread/7bb610e206733fdf/
70757e6c50a8dfb6?hl=en&lnk=gst&q=subbarayan#70757e6c50a8dfb6

P.S:ours is an consumer electronics product.Processor:ST,EEPROM:ST's
M24128BW .

This solution may or may not be suitable to you depending on your
product.

Thank you.

Hope this helps,
Regards,
s.subbarayan

--

John Devereux- Hide quoted text -

- Show quoted text -

Hi John,
I will continue using brackets while posting long links.
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?
On what basis you would come to know data is valid given that you dont
have a checksum?

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.

Looking farward for your reply and advanced thanks,
Regards,
s.subbarayan
.



Relevant Pages

  • Re: EEPROM guarantees after power loss during a write
    ... I am wondering what guarantees are there for existing EEPROM data, ... Say power is lost during a write to a single byte in a page. ... comparing with known checksum). ... mark copy 1 invalid ...
    (comp.arch.embedded)
  • Re: Saving data in CPU on-chip EEPROM
    ... > What happens if during saving the parameter in byte of EEPROM(it takes ... > about 5-10 msec)the Power Down occurs.What should be in the byte ... > processor.The system manages failure ... > always recalculate the new checksum after each parameter ...
    (comp.arch.embedded)
  • Re: Encrypting Harddisk?
    ... > motherboards eeprom. ... Any service interruption in the webcam coverage, motion, power interruption, ... If you want to get wacko about it, use the really *old* aluminum disk packs ... the disk, finely spraying the case with finely powdered, fresh, ...
    (comp.os.linux.security)
  • Re: Encrypting Harddisk?
    ... > motherboards eeprom. ... Any service interruption in the webcam coverage, motion, power interruption, ... If you want to get wacko about it, use the really *old* aluminum disk packs ... the disk, finely spraying the case with finely powdered, fresh, ...
    (comp.os.linux.security)
  • Re: Temperature Control -- PID -- Heater
    ... Setpoint is a constant 405degF. ... >Saving the iterm in eeprom would shorten the eeprom's life. ... >can live with a zeroe'ed out iterm after a quick power failure. ... Alternative thought some form of delayed power off for quick power ...
    (comp.arch.embedded)

Loading