"Flakey" internal eeprom corruption

[starfire151]

I am using version 3.249 of the compiler on a pair of PICs. The first PIC is a 12F675 and is acting as a "power mizer" to extend battery life. It runs at 32.768KHz and 3.0VDC. I'm using it to act as a timer to enable power to the second PIC, an 18LF2620 running at about 20MHz and 3.3VDC. The 18LF2620 is running my main application which runs everytime power is applied. At the conclusion of the main routine, the 18LF2620 sends a command to the 12F675 to turn the power off. When the 12F675 sees the power off command, it removes power from the 18LF2620 and counts for a preset number of seconds before turning the power back on. That's the fundamental operation of the system.

Now the problem... Since the 18LF2620 is powering down everytime, I have to save various variables in internal eeprom and read them all at power up. When the variables have changed through program execution, I save the updated values to the eeprom before exiting. "Most" of the time, this works well. "Some" of the time I get corrupted values stored to the eeprom, which reeks havoc the next time I power up

I store upwards of 15 bytes worth of data everytime I power up. Is there a minimum amount of time I should be waiting between writes to ensure write success? I would like to avoid having to read all the values back to confirm they've written correctly, if I can help it...

Thanks for any help.

[PCM programmer]

[starfire151]

I'm using an output pin on the 12F675 to control an N-Channel MOSFET which controls a P-Channel MOSFET to enable power to a LT1121 voltage regulator which supplies the 3.3VDC to the main board components, including the 18LF2620. I use a 47K resistor and a 10uF cap on the reset line of the 18LF2620 to ensure a good start. The powering up sequence seems to be reliable and repeatable.

[PCM programmer]

[starfire151]

OK... I can try that to reduce the power-up time of the 18LF2620 when switched on. Could this cause a corruption of the eeprom during normal operation, though? I inserted 10ms delays after each and every eeprom write in the program and (so far... knock on wood), it appears to be working. The reason for the long time constant during power up was to eliminate a synchronization problem between the two PICs. I have come up with an "improved" synchronization now, though, so the historical need for that long a time constant is no longer necessary.

[newguy]

I seem to remember ~5ms being a typical EEPROM write time.

[starfire151]

Thanks... I'll probably tweak the delay value down if this test works successfully.

[newguy]

That processor has an interrupt for when a write to the internal EEPROM completes. #int_EEPROM.

I have to ask, though, how often do you write values to EEPROM? The PIC's internal EEPROM can fail in as little as 10,000 writes. I'd recommend using a ramtron memory chip instead, as they can withstand an essentially infinite number of write cycles. They're also much faster.

[starfire151]

Ouch! Where did you get that number? I didn't see that parameter in the data sheet for the part.

I agree an external high-speed ramtron device would be highly advantageous but, unfortunately, the "die is cast" and the boards are built. Its on the wish-list for the next revision, though.

[newguy]

Sorry, the 2620 is rated for 100,000 cycles minimum. My mistake. Most of the processors I've used are typically rated for 10,000, so that's where I got the figure from. The endurance specs are found on page 339 (table 26-1) of the data sheet.