Checking if value stored in internal EE is corrupt

[RobS]

I am using a PIC 18LF8720. CCS compiler PCWH ver 3.206.
I need to update a count every minute and save it to the internal EE. I was concerned that the value could get corrupt because it is two bytes stored in two separate locations. Although unlikely something may happen between the 1st and 2nd write. I thought saving two copies and then checking to make sure the values are the same would be the thing to do. Every minute the following is done:

Num1 = read_EE(EE_adr1)
Num2 = Read_EE(EE_adr2)
If Num1 != Num2
Flag = 1
Num1++
write_EE (EE_adr1, Num1)
write_EE (EE_adr2, Num1)

When the host requests the vaule of Num1 it sends a command to the PIC. If Flag == 1 it sends a response indicating the value is corrupt and then requires the system to set Num1 to 0, save it at EE_adr 1 and EE_adr2 and clear Flag to 0. If Flag == 0 then it just returns the requested value.

Num1 and Num2 are type int16 and EE_adr1 and EE_adr2 are type int8.

Since Num1 and Num2 are int16 the write_EE function separates the variable into a hi and lo byte and stores each at a separate address. The read_EE function retrieves the two values and returns an int16 value.

The above is implemented on several machines and is in use for several weeks. Occasionally the Flag gets set. One problem with the above is I don�t know if it occurred during the Write or Read potion. Also the address is an int8 type.

Could the int8 address type be the most likely cause the flag is being set?

I am planning to implement a revised check, with an int16 type address:

Num1 = read_EE(EE_adr1_16)
Num1++
write_EE (EE_adr1_16, Num1)
Num2 = read_EE(EE_adr1_16)
If Num1 != Num2
Flag = 1

It uses only one write instead of two.

Do you think this is the proper way to check for a corrupt value or would you recommend a different method?

Thanks

[Ttelmah]

I feel a bit like the guy standing next to the person trying to jump off a bridge...
Don't do it.

Redesign your circuit. Either add an external memory like FRAM, or add a low voltage power-out detection circuit, and write the EEPROM once. You will exceed the write 'life' of the typical internal EEPROM, in about 9months, and the life of the 'worst case' example, in less than a month.
You can use LVD, and a capacitor to maintain the supply for the write time of the EEPROM.

Best Wishes

[valemike]

At your rate of eeprom writing (once a minute), Ttelmah's right, you'll wear it out in no time.

I didn't read the post thoroughly but, i think you are referring to a 16-bit variable that can change in an ISR. Why dont you do the following:

disable_interrupts(GLOBAL);
reentrant_num1 = num1;
reentrant_num2 =num2;
enable_interrupts(GLOBAL);

Now you can do what you want to reentrant_num1 and reentrant_num2 and be assured they are in sync. You wouldn't want to disable interrupts during the eeprom transactions because they take too long.

However, how many write cycles are there in the eeprom? Isn't it a couple million? At one write per minute, then you'll reach 1M writes in 60 minutes * 24 hours = 694 days. That's almost 2 years.

If your warranty period is only 1 year, then you'll make a bundle in aftermarket repairs on the 2nd year!

By the way, is num1 and num2 a 16-bit value? or are they two independent bytes?

[libor]

[RobS]

Thanks for the response guys. The machine actually runs 7 to 8hrs a day, 5 days per week so there is a little more time. That�s a good suggestion to monitor the power and write once or external memory. I can�t redesign the board now but plan to in the near future.

I looked at the assembly generated code for EEPROM transactions and I believe interrupts are disabled during this time.

The variable that gets updated is a 16 bit number. If power was lost between the 1st and 2nd write wouldn�t that be a problem? Also do you think it was a problem using an 8 bit data type for the EEPROM address?
Thanks

[valemike]

I took any datasheet, in this case the 18f4525, and it says that you can have "1,000,000 erase/write cycles"

I don't know the answer to whether it's 1M cycles per byte, per bit, or per the whole thing. However, i did hear of techniques (not necessarily on the PIC) where people attempt "even wear" of each of the eeprom bytes, so they write to different areas evenly.

If your board hasn't been laid out yet, you're better off going to nvram that allows much more writes.

You also might want to look at the crc examples in the CCS library to ensure multiple bytes are in fact not corrupted. And you should do some double-banking of your data in eeprom (or whatever nonvolatile RAM) you choose to use.

[Ttelmah]

Caveat here.
the one million cycle life, is 'typical'. If you are designing, and want stuff to be reliable, you should instead work closer to the 'worst case' specs, and this is only 100000 cycles....
Generally, on EEPROMs, the 'life' is per block, and for writes only (reading does not degrade the life). So one solution, to extend the life massively, would be to 'walk' the memory. If you write the value required, together with a 'marker', that increments, then move to the next group of cells, when power is restored on a system, you look through the groups, for the last 'marker', take this value, and start from the same point, if the marker and data are four bytes, and the EEPROM is 256 bytes, you could potentially give yourself 64* the individual cell 'life'.

Best Wishes