1. Home
  2. Embedded Programming
  3. CRC calculation for variables stored in eeprom

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

Reply to
ssubbarayan
Loading thread data ...

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

Reply to
jetmarc

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.

Reply to
Marra

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

--
 
 
 
 
                        cbfalconer at maineline dot net
Reply to
CBFalconer

Hi, Its infact eeprom utilised as a nvram.

Regards, s.subbarayan

Reply to
ssubbarayan

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:

-- Posted via a free Usenet account from

formatting link

Reply to
CBFalconer

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

Reply to
Peter Dickerson

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.

Reply to
Anders

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.