> What happens if the power
> failure comes while you are writing the flag, so that it is erased but
> not yet programmed with the new value?  When you power up and read it,
> the flag could be 0xff.

Actually it could be almost any other value as well.  When the erase or
the program operation is interrupted "in the middle", it could happen
that some of the bits are already erased (or programmed) while others
are not.

The probability of this to happen depends on the process tolerance.
Since all bits are intended to be manufactured equally, the power fail
time window is quite small.  However, it's not impossible, and less so
if somebody deliberatly looks for it (to attack the application).

You can avoid this by the following algorithm:

a) Reserve a large empty area of byte-write eeprom memory for the
"status".

b) Add a version number to the "status" (ever increasing number) to be
able to determine the latest from several versions of "status".

c) When writing the status:

  1) find an "empty" slot in the eeprom memory, 2 bytes larger than
your "status"
  2) write the last byte of the slot to 0xff
  3) write the first byte to 0x00.  This indicates that this slot is
"writing"
  4) write "status" in between these two bytes
  5) write the last byte to 0x00.  This indicates that this slot is
"valid"

d) When reading the status:

  1) read all memory slots that have the first and last byte 0x00.
  2) using the version number, determine which one is the last one and
ignore the others.

e) When you can't find an empty slot (eeprom full):

  1) find an invalid slot (which doesn't have both bytes set to 0xff),
or the oldest version of"status"
  2) write the last byte to 0xff.  This indicates "writing".  Go on as
shown in c)

This helps against power failure of any kind at any moment.  It also
spreads the wear over the eeprom memory, increasing the maximum number
of writes.  You can use a shorter write cycle time if you want.

Kind regards,
Marc

Look at the FRAM devices from RAMTRON, they have 'instant writes', so
are immune to power-fails-while-writing errors.
IIRC, they have a 24C16 clone ( and larger ones too )
-jg

Bubb wrote:
> "Roberto Waltman" <usenet@rwaltman.net> wrote
> 
> 
>>What is the granularity of the EEPROM for write/erase operations?
> 
> 
> I dont understand?
> 
> The memory is an 24C16. The data sheet is at
> http://www.st.com/stonline/books/pdf/docs/5067.pdf.
> 
> 
>>Can you erase and reprogram single bytes, sectors, how many?
> 
> 
> Singel bytes, yes.
> 
> 
>>Do you get an early warning that power is about to fail?
> 
> 
> No
> 
> 
>>If you do, do you have enough time left to complete an erase/write
>>operation?
> 
> 
>>Is your code running from the same EEPROM were you want to log the
>>information? (Unlikely, but *very* important.)
> 
> 
> No
> 
> 
>>Is there any risk that all the information in the EEPROM may be lost
>>if an erase or write is aborted?
> 
> 
> I dont think so.
> 
> 
>>How many cycles can the EEPROM endure? What is the expected lifetime
>>of the device where it is being used? (100,000 max erase cycles at 30
>>minutes rate --> ~5.7 years lifetime. Is this enough?)
> 
> 
> 1 million erase/write cycles and it can hold the data for 40 years. The
> lifetime is enough.
> 
> 
>>>I thought of an idea where i save the runtime at two different locations
> 
> in
> 
>>>the EEPROM + a flag 0 or 1 that indicate where i was able to store the
>>>latest runtime.
>>
>>And another flag to recover the value of that flag? And another? ;)
> 
> 
> Maby some checksum instead?
> 
> 

"Bubb" <bubb@telia.se> wrote:
>If the byte error is only on the last byte written then I could write all
>data twice. And when I read the data at the next power up I can se if the
>copies don't match.

Only if valid data for any byte can never be equal to the value of
memory after erasure. See my second post in this thread.

> And if they don't match I use another (older) data from
>the EEPROM.

"Bubb" <bubb@telia.se> wrote:
>"Roberto Waltman" <usenet@rwaltman.net> wrote
>
>> What is the granularity of the EEPROM for write/erase operations?
>I dont understand?

That means what is the size of the smallest units you can erase or
rewrite. I believe for all EEPROM devices it is single bytes, but I am
not sure. (For FLASH devices it is whole sectors)

>The memory is an 24C16. The data sheet is at
>http://www.st.com/stonline/books/pdf/docs/5067.pdf.
>
>> Can you erase and reprogram single bytes, sectors, how many?
>
>Singel bytes, yes.
>
>> Do you get an early warning that power is about to fail?
>
>No

I read Jack Klein's answer after posting mine. As he said, there is no
way you can guarantee that the information will be saved successfully
if power can be removed in the middle. What you can do, is make sure
that you can detect if the information is corrupt, and act
accordingly.

>> If you do, do you have enough time left to complete an erase/write
>> operation?
>
>> Is your code running from the same EEPROM were you want to log the
>> information? (Unlikely, but *very* important.)
>
>No
>
>> Is there any risk that all the information in the EEPROM may be lost
>> if an erase or write is aborted?
>
>I dont think so.
>
>> How many cycles can the EEPROM endure? What is the expected lifetime
>> of the device where it is being used? (100,000 max erase cycles at 30
>> minutes rate --> ~5.7 years lifetime. Is this enough?)
>
>1 million erase/write cycles and it can hold the data for 40 years. The
>lifetime is enough.
>
>> >I thought of an idea where i save the runtime at two different locations
>in
>> >the EEPROM + a flag 0 or 1 that indicate where i was able to store the
>> >latest runtime.
>>
>> And another flag to recover the value of that flag? And another? ;)
>
>Maby some checksum instead?

This is one way of doing it:

I would implement a circular buffer with two or better, more slots for
logging the information you need.

Each time you want to save the information, locate an available slot
that should be erased already, (more on this later), and save the
following:

(1) Your data.
(2) An counter field which is incremented each time its saved. This
will allow you to identify the most current slot.
(3) A checksum to verify the integrity of the data. (Make sure to
select a checksum algorithm that will never produce a value similar to
the contents of memory after erasure.)

A counter value of zero, or a value for the checksum similar to erased
memory can be used as flags to mark that the slot is available, or add
a fourth field for this purpose
 
After the data was saved successfully, locate the oldest slot, (based
on the counter on (2) above), and erase it so it will be ready for
next cycle. The reason to split the erasure from the writing of the
data, is to reduce the likelihood of a power failure happening while
the EEPROM is in an inconsistent state while saving the latest
information.

What if a power failure happens at any point? 
To recover, at power up the system should do the following:
Scan the circular buffer and mark for erasure all slots that fail a
checksum verification. From those that checked OK, save the highest
value of the counter and use it to continue the process.
If all slots are OK and none is erased, erase the oldest one to be
ready for the first write cycle.

(Fill the blanks for boundary scenarios like all slots erased, all
corrupt, two blocks with the same counter, etc.)

Of course this does not assure that the data will always be saved. For
that you need hardware support. (May be as simple as a "super-cap")
If you can not tolerate the risk of losing 30 minutes worth of
information you can reduce the risk (but not eliminate it) by saving
it at shorter intervals.

Hope this helps,

Roberto Waltman

Made an error,, here it is again :-)

If the byte error is only on the last byte written then I could write all
data twice. And when I read the data at the next power up I can se if the
copies don't match. And if they don't match I use another (older) data from
the EEPROM.

Like this:

ADDR[0] = A(n)
ADDR[1] = B(n)
ADDR[2] = C(n)
ADDR[3] = D(n)
ADDR[4] = E(n)


ADDR[5] = A(n)
ADDR[6] = B(n)
ADDR[7] = *        <--- power faild when writing this byte, corrupt value
ADDR[8] = D(n-2)
ADDR[9] = E(n-2)

ADDR[10] = A(n-1)
ADDR[11] = B(n-1)
ADDR[12] = C(n-1)
ADDR[13] = D(n-1)
ADDR[14] = E(n-1)


ADDR[15] = A(n-1)
ADDR[16] = B(n-1)
ADDR[17] = C(n-1)
ADDR[18] = D(n-1)
ADDR[19] = E(n-1)

Then I alter between writing to ADDR[0-9] and ADDR[10-19].

If the byte error is only on one byte written then I could write all data
twice. And when I read the data at the next power up I can se if the copies
don't match. And if they don't match I use another (older) data from the
EEPROM.



Like this:



ADDR[0] = A(n)

ADDR[1] = B(n)
ADDR[2] = C(n)

ADDR[3] = D(n)

ADDR[4] = E(n)




ADDR[5] = A(n)

ADDR[6] = B(n)

ADDR[7] = *        <--- power faild when writing this byte, corrupt value

ADDR[8] = D(n-1)

ADDR[9] = E(n-1)





ADDR[10] = A(n-1)

ADDR[11] = B(n-1)
ADDR[12] = C(n-1)

ADDR[13] = D(n-1)

ADDR[14] = E(n-1)




ADDR[15] = A(n-1)

ADDR[16] = B(n-1)

ADDR[17] = C(n-1)

ADDR[18] = D(n-1)

ADDR[19] = E(n-1)



Then I alter between writing to ADDR[0-9] and ADDR[10-19].

"Jack Klein" <jackklein@spamcop.net>

> Does your hardware provide advance notice of power off, with enough
> time to complete an EEPROM write?

No

> > I thought of an idea where i save the runtime at two different locations
in
> > the EEPROM + a flag 0 or 1 that indicate where i was able to store the
> > latest runtime.
>
> There are problems with this if you don't have advanced power fail
> warning.  You are writing to multiple locations, and vulnerable to
> power failure in between the writes.  What happens if the power
> failure comes while you are writing the flag, so that it is erased but
> not yet programmed with the new value?  When you power up and read it,
> the flag could be 0xff.

Didn't think of that one. Thanks for pointing it out.

> If you must do this without power fail warning, look up how journaling
> file systems work.  It is more work, but you can make it just about
> impossible to lose information even if there is a power down without
> warning in the middle of an update.

Thank you, I will search for information about that.

"Roberto Waltman" <usenet@rwaltman.net> wrote

> What is the granularity of the EEPROM for write/erase operations?

I dont understand?

The memory is an 24C16. The data sheet is at
http://www.st.com/stonline/books/pdf/docs/5067.pdf.

> Can you erase and reprogram single bytes, sectors, how many?

Singel bytes, yes.

> Do you get an early warning that power is about to fail?

No

> If you do, do you have enough time left to complete an erase/write
> operation?

> Is your code running from the same EEPROM were you want to log the
> information? (Unlikely, but *very* important.)

No

> Is there any risk that all the information in the EEPROM may be lost
> if an erase or write is aborted?

I dont think so.

> How many cycles can the EEPROM endure? What is the expected lifetime
> of the device where it is being used? (100,000 max erase cycles at 30
> minutes rate --> ~5.7 years lifetime. Is this enough?)

1 million erase/write cycles and it can hold the data for 40 years. The
lifetime is enough.

> >I thought of an idea where i save the runtime at two different locations
in
> >the EEPROM + a flag 0 or 1 that indicate where i was able to store the
> >latest runtime.
>
> And another flag to recover the value of that flag? And another? ;)

Maby some checksum instead?

"Bubb" <bubb@telia.se> wrote:

>I want to log the total runtime of an application to an EEPROM. But I must
>have a secure method to do that if the application get turned of at that
>moment when I write the data to the EEPROM.
>
>The runtime is going to be saved to the EEPROM about every 30 minutes or so.
>
>
>Any suggestions?

A few questions first:

What is the granularity of the EEPROM for write/erase operations?
Can you erase and reprogram single bytes, sectors, how many?
Do you get an early warning that power is about to fail?
If you do, do you have enough time left to complete an erase/write
operation?
Is your code running from the same EEPROM were you want to log the
information? (Unlikely, but *very* important.)
Is there any risk that all the information in the EEPROM may be lost
if an erase or write is aborted?
How many cycles can the EEPROM endure? What is the expected lifetime
of the device where it is being used? (100,000 max erase cycles at 30
minutes rate --> ~5.7 years lifetime. Is this enough?)

>I thought of an idea where i save the runtime at two different locations in
>the EEPROM + a flag 0 or 1 that indicate where i was able to store the
>latest runtime.

And another flag to recover the value of that flag? And another? ;)

On Tue, 27 Jun 2006 19:34:30 +0200, "Bubb" <bubb@telia.se> wrote in
comp.arch.embedded:

> I want to log the total runtime of an application to an EEPROM. But I must
> have a secure method to do that if the application get turned of at that
> moment when I write the data to the EEPROM.

Does your hardware provide advance notice of power off, with enough
time to complete an EEPROM write?  If not, there is no dependable way
to do this.

> The runtime is going to be saved to the EEPROM about every 30 minutes or so.
> 
> 
> 
> Any suggestions?

Usually, some sort of voltage monitoring circuit is placed in front of
the voltage regulators, on the higher voltage DC or the AC line.  If
the power starts to drop, the monitor circuit triggers an interrupt to
the processor.  Then all you need is enough capacitance to keep the
power in tolerance long enough to write to the EEPROM.

If you do not have such a circuit, and cannot add one to your design,
you are at risk of losing data.

> I thought of an idea where i save the runtime at two different locations in
> the EEPROM + a flag 0 or 1 that indicate where i was able to store the
> latest runtime.

There are problems with this if you don't have advanced power fail
warning.  You are writing to multiple locations, and vulnerable to
power failure in between the writes.  What happens if the power
failure comes while you are writing the flag, so that it is erased but
not yet programmed with the new value?  When you power up and read it,
the flag could be 0xff.

If you must do this without power fail warning, look up how journaling
file systems work.  It is more work, but you can make it just about
impossible to lose information even if there is a power down without
warning in the middle of an update.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html