Forums

Log runtime to EEPROM?

Started by Bubb June 27, 2006
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?



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.



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
"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? ;)
"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?
"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.
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].


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].


"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
"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.
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? > >