Javier:

There are varying opinions on this subject from forum participants as I recall this from the extended discussion that was had here some time back. But let me tell you what I do.

I divide up the parameter sets in the EEPROM into small functional blocks that are groups from 2 or 3 up to maybe 6 -> 8 bytes. I store the data into the EEPROM with a check code attached. The check code is computed across the small data set and then stored as a byte appended to the data set.

I store two identical copies of each data set. They are stored sequentially so that if there is a power glitch or accidental shutdown while one is being written I know that either the first copy has been stored correctly if the interruption happened while the 2nd copy was being written. On the other hand if the interruption happened while the first copy is being written there is a 2nd copy from the previous save that is still there but has not been interrupted.

At time of loading I read the first copy. If it's check code is OK I then use that data and don't bother with the second. On the other hand if the first check code does not verify then I go on to the second data set and read that in. Now under the aformentioned scheme of writing the the data in the first place, the 2nd check code will almost always show good and so I would go ahead and use that data knowing that it is only one generation old. If the 2nd check code does not validate it is then necessary to take some action. I use two different action schemes depending upon the function of the parameter set and how it is used in the system. One method is to simply apply default values to the parameters and re-write two copies to the default. The other senario is to stop and alert the operator or host master controller of the situation and await higher level interaction.

One of the arguments I have heard about this scheme is that a 1 byte check code is not good enough. Well to that I will say that I concocted some tests a year ago where I stress tested my check code algorithm on parameter sets with 3 bytes plus 1 check byte. I wrote the stress test to replace one byte out of the three across which the check is computed with each of the 255 possible wrong byte values. This was done with 255 combinations of the 1st byte, then 255 combinations of the 2nd and so forth through the 3th byte. The tests were run across the universe of all possible 3 byte parameter combinations (i.e. 2^^24). In no case did my check code fail to detect the data sets with the substituted bad bytes. Now it took the PC running the stress test quite a while to do its thing and so I never ran the scheme for a 4 byte parameter set (2^^32 combinations). I felt that a test that buggered one byte in a parameter set was a good test because it represents what can typically go wrong in a firmware implementation on a microcontroller hardware platform with a serial EEPROM.

Another argument I have heard about this scheme is that why bother with check codes. Just use two data set copies and compare the them for 100% equality. The problem with this scheme is that if they do not match then you do not have a clue as to which one is right and which is wrong.

A third argument that that you will hear is that one should then use three copies of the data set since two copies does not work. Well it is certainly possible to use 3 copies. One can easily do 100% comparison of the data but if there are mis-matches it is necessary to do up to 3 sets of compares (i.e. A <-> B, A <-> C, and B <-> C) to decisevely determine if one particular pair of copies represents the most recent valid copy of the data. The compares are no big deal in a system with small data sets. The issue that I encounter however is to consider how much time it takes support a 3 copy scheme versus a 2 copy+check scheme and how much in the way of processor memory bytes are used. For small data sets it takes about the same anount of time to maintain a two copy scheme versus a 3 copy scheme. For larger data sets the check code scheme will show lesser time to update the EEPROM. The EEPROM update time can be an issue in an embedded system when there are real time bandwidth issues to take into account. Consideration of the RAM resources should be made too. The 2 copy+check scheme only requires enough processor RAM to hold one copy of the parameter set and those can be the same locations that hold the in RAM work copies of the parameters. The three copy scheme requires more resources during reading in order to verify. If you have one memory buffer then each EEPROM copy of the data may need to be read up to 2 times to find the valid data match. On the other hand if you have two RAM buffers allocated then each copy need only be read once. The number of times to write or read EEPROM each byte is important too because on a serial device (especially a software bit-banged interface) it takes a goodly amount of time to read a byte. As I have weighed all these considerations I have found the two copy+check scheme to work out the best for my needs. The chart below compares the two schemes for various sizes of parameter sets.

Click on chart to see actual Excel SpreadSheet.

Here is a copy of my check code calculation scheme written in C code. (I have used this on PC, PIC, HC05, HC08, and 8051/8052) !!

/*
**
** routine to calculate EEPROM check digit
**
*/

unsigned char check_calc(unsigned char *dat,unsigned char len)
{
    unsigned char chk;
    unsigned char bit;

    chk=0;
    while(len--)
    {
        chk^=*dat++;
        bit=(chk & 0x80 ? 2 : 1);
        chk<<=1;
        chk+=bit;
    }
    return(chk);
}

Have Fun
MICHAEL KARAS