CRC calculation for variables stored in eeprom

Dear all,
     I have posted a couple of months back about eeprom corruption and
some experts here adviced me to stored a CRC value for the memory
contents to determine corruption.Regarding this I have got a query:
In our case,the contents in the eeprom change dynamically in run
time.Does that mean everytime we need to update the CRC too?As an end
user how would I know which value of CRC is correct at a given point
of time if the eeprom content gets updated dynamically?One more thing
to note here is we have thirdparty application which writes to eeprom
and we provide drivers.Is there anything that could be done from
drivers for this issue?We are not in a position to afford to have a
copy of eeprom contents due to limited memory.

Looking farward for your replys and advanced thanks for the same,
Regards,
s.subbarayan

Hi,

It all depends on your driver API.

If you allow the thirdparty application to update single bytes at any
time, then you're in trouble. There's almost no way to reliably do the
memory update.

You would need to memorize in some isolated place that an update will
happen and to what address.  You would need to memorize the value to
write (in case the write gets interrupted) and what the new checksum
is.  Then you would do the update in-place, and eventually you will
erase the isolated place to indicate that the write has terminated.

On powerup, you would check the special locations to see if there was
an interrupted write.  If there was, you would repeat the write and
erase the special place afterwards.  Only then the memory should be
"consistent" and you can start to calculate and verify the checksum.

However, this will make your single-byte write function several times
slower.

Your best bet will be to try to get your hands on the thirdparty
application.  Most of the times it is possible to come up with an API
which suits the application and at the same time allows you to
implement a kind of "transaction" scheme in your driver, for reliable
checksums and better performance.

Regards,
Marc

On 12 Jun, 09:56, jetm...@hotmail.com wrote:
> Hi,
>
> It all depends on your driver API.
>
> If you allow the thirdparty application to update single bytes at any
> time, then you're in trouble. There's almost no way to reliably do the
> memory update.
>
> You would need to memorize in some isolated place that an update will
> happen and to what address.  You would need to memorize the value to
> write (in case the write gets interrupted) and what the new checksum
> is.  Then you would do the update in-place, and eventually you will
> erase the isolated place to indicate that the write has terminated.
>
> On powerup, you would check the special locations to see if there was
> an interrupted write.  If there was, you would repeat the write and
> erase the special place afterwards.  Only then the memory should be
> "consistent" and you can start to calculate and verify the checksum.
>
> However, this will make your single-byte write function several times
> slower.
>
> Your best bet will be to try to get your hands on the thirdparty
> application.  Most of the times it is possible to come up with an API
> which suits the application and at the same time allows you to
> implement a kind of "transaction" scheme in your driver, for reliable
> checksums and better performance.
>
> Regards,
> Marc

I think you need to go back to basics.
If you are getting corruption then you are likely doing something
wrong.
Are your timings too fast for the EEPROM?
Do you make sure you get an ack at the end of the data write?

I have never in 25 years had corrupted data in an EEPROM.

ssubbarayan wrote:
> 
> I have posted a couple of months back about eeprom corruption and
> some experts here adviced me to stored a CRC value for the memory
> contents to determine corruption.Regarding this I have got a query:
> In our case,the contents in the eeprom change dynamically in run
> time.Does that mean everytime we need to update the CRC too?As an
> end user how would I know which value of CRC is correct at a given
> point of time if the eeprom content gets updated dynamically?One
> more thing to note here is we have thirdparty application which
> writes to eeprom and we provide drivers.Is there anything that
> could be done from drivers for this issue?We are not in a position
> to afford to have a copy of eeprom contents due to limited memory.

Sounds as if you don't really have an eeprom.  A better hardware
description is needed.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

Hi,
Its infact eeprom utilised as a nvram.

Regards,
s.subbarayan

ssubbarayan wrote:
> 
> Its infact eeprom utilised as a nvram.

This has no meaning, lacking any quotation.  Read my sig below.

-- 
 If you want to post a followup via groups.google.com, ensure 
 you quote enough for the article to make sense. Google is only
 an interface to Usenet; it's not Usenet itself. Don't assume
 your readers can, or ever will, see any previous articles.
More details at: <http://cfaj.freeshell.org/google/>



-- 
Posted via a free Usenet account from http://www.teranews.com

"ssubbarayan" <ssubba@gmail.com> wrote in message 
news:1181708623.137402.286620@n15g2000prd.googlegroups.com...
> Hi,
> Its infact eeprom utilised as a nvram.

I'm not sure that that is (strictly) possible, since there many timing and 
sequencing issues.

The reverse - using an NVRAM as an EEPROM is more practical.

Peter 

ssubbarayan wrote:
> Hi,
> Its infact eeprom utilised as a nvram.
> 
> Regards,
> s.subbarayan
> 

Then maybe that's your problem. An EEPROM has a limited number
of write cycles per cell. If you write to it a lot you'll kill
it pretty quick.

Like one of the other responders, I've used EEPROMs a lot, with
 >100k installations running, and corrupted data has never been
a real problem, but I rarely write to the same cell twice.

</A>