Electronic – EEPROM data check

crceeprompic

I am communicating with an EEPROM chip with micro controller.
I am writing certain data in to specific addresses in EEPROM and needs to check the data occasionally. But I have no idea other than reading back from the written address of the EEPROM to check whether the data is corrupted.

I have heard of CRC routines and Xor Routines.What are the common practices for checking the corrupted data.It would be helpful for my design.
I'm posting the method i know:

step1: Write data in to EEPROM and store that in a variable.
step2. Read the data back and check with the stored variable.

I trust there must be standard procedures to check whether
the data in EEPROM is corrupted or not.

It would helpful if you help me to suggest me the way forward.

Best Answer

The problem with your approach is that the EEPROM data is permanent, whereas the variable is volatile. Once the device is power cycled, how will you check the data in the future? The variable is gone, and all you have is the EEPROM copy.

What you have so far is not a data integrity strategy, but only a write verification step (which is wortwhile; don't misunderstand).

You could store checksums along with the data; however, checksums can only tell you that the data is corrupted. This is better than proceeding with corrupted data; however, if the data is critical, it means that the device has failed.

A more robust solution is to store the data in such a way that not only error detection is possible, but also error correction.

You can implement a Hamming codes for individual words of the data. A Hamming code can recover from a single-bit error; more with some extensions.

If you have lots of space on the EEPROM, you can implement redundancy. For instance, you can split the EEPROM into two halves which mirror each other, similar to a RAID0 scheme used for hard disks. Write every unit of data in both partitions, with block checksums. When reading data, if a checksum is bad, you can try the other copy it in the mirrored partition. Chances are its checksum is good. (And if so, you can overwrite the bad copy with the good copy to repair it.)