3
\$\begingroup\$

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.

\$\endgroup\$
6
\$\begingroup\$

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

\$\endgroup\$
  • \$\begingroup\$ I've been using this scheme for years and years in many products. Only thing different is that I check each block contents with a CRC or XOR type check code. Simple additive checksums are not robust enough for validating the content of even small blocks of data. \$\endgroup\$ – Michael Karas Nov 16 '13 at 17:02
  • \$\begingroup\$ @MichaelKaras Re: "only thing different" I didn't say anywhere to use an simple additive checksum. CRC is a type of checksum (Cyclic Redudancy Checksum). Of course that's what should be used whenever possible. \$\endgroup\$ – Kaz Nov 16 '13 at 18:00
  • \$\begingroup\$ I guess one can choose your abbreviations as desired. CRC for me was always "cyclic redundancy code" whilst checksum has always been a check code created by summing all the numbers in a stream modulo some bit width. \$\endgroup\$ – Michael Karas Nov 16 '13 at 21:31
  • \$\begingroup\$ @MichaelKaras Actually, I'm slightly wrong. CRC stands for Cyclic Redundancy Check, (not Checksum). The word checksum is used in a general way in computing to denote any kind of hash used for data integrity. MD5 and SHA are sometimes called checksum algorithms. \$\endgroup\$ – Kaz Nov 17 '13 at 0:55
2
\$\begingroup\$

CRC and Checksum routines also need to read back the data. The idea is that they can condense a large section of data down into just a couple of bytes that need to be checked. If you just wrote a block of data from a buffer in memory out onto the EEPROM chip, then just reading it back off the chip and comparing would be the simplest solution. However, if you don't have the entire data block in memory at the same time, then you can either confim incrementally (write a byte, read it back, write the next byte, read it back, etc.) or compute a CRC or checksum of the bytes as they are written, then go read then back later, compute the CRC or checksum of the bytes you read, then compare.

\$\endgroup\$
  • \$\begingroup\$ Can the CRC or Checksum utilized for whole eeprom memory?. Is there any limit on the total memory that can be checked? \$\endgroup\$ – Rookie91 Nov 16 '13 at 6:11
  • \$\begingroup\$ Both of these are algorithms for distilling a large block of memory down into a small, easy to compare value. There is no limit to how large of a memory block you can create a CRC or a checksum of. \$\endgroup\$ – alex.forencich Nov 16 '13 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.