eeprom data corruption (?)

[Drone601]

Seem to be having trouble with eeprom write or read in PIC16F18345. Using it in a device where the user has the choice of a few settings. When (and only when) the user pushes a button to change settings, the new setting is written to eeprom so if the device loses power it will restore to that setting when powered up again.

Generally this works fine. But 1 time out of, say, 100 power-ups, the eeprom read is incorrect and the device restores to a wrong setting. The device also keeps track of its total run hours, and it's showing a similar issue. It's so intermittent that it's hard to catch, but by chance I once saw it jump 6 hours between one power up and the next, a minute later. There's evidence that on other occasions it has jumped thousands of hours.

And once wrong, it stays wrong. Subsequent reads don't show the right value.

I can see how the elapsed time issue might be a code error in marking time. But it seems to be totally random across multiple devices (we've made several). Such an error would more likely show some kind of consistency, yes? And the setting change routine is pretty straightforward, requiring confirmed physical button-pressing. So it *seems* to me that the eeprom data is somehow getting corrupted at random times. I can try doing a write / read / confirm to be sure it's written correctly. For reasons, I don't have eeprom space to redundantly store data.

Any ideas / suggestions / comments?

[asmallri]

[Drone601]

Thanks for the reply Andrew.

I'm afraid I do have BOR enabled.

[temtronic]

other possible causes

1) noisy power supply
2) lack of EMI protection
3) poor/marginal _MCLR hardware
4) bad grounding/ poor solder connections
5) insufficient PSU capacity

Jay

[Ttelmah]

Supply issues are the commonest cause of EEPROM problems. The chip
needs a clean supply through the whole of the write.

An EEPROM write has to erase the cell. This normally requires a higher
supply voltage than the BOR may trigger at. The brown out reset threshold
needs to be at it's 'high' threshold to ensure a reset before this.
Also understand that if the supply is falling and a reset occurs during the
write, this will result in corrupted data. This is why it can be necessary to
actually test the supply level before a write is started, and ensure that the
capacitance on the rail is sufficient to guarantee that the supply will stay
in the safe region for the entire write duration.

However there are some comments that are raising 'alarms'. You talk about
saving a time. How often?. Is there any possibility that the routine to do
this could be called 'mid way through' writing the button data?. Or, what
would happen if the button routine, stopped this from being written?.

[temtronic]

I've had a couple more ideas....

1) add code to write, say once per hour a value (say 127 for odd hrs, 64 for even). This opertion would be inline code NOT triggered by the button press. If this works 100%, then I'd say a 'glitch' or noise from the button press is somehow corrupting the EEPROM data storing routine. Something like the PB trace next to the _MCLR line might account for that.

2) You post about storing the 'time'. If you have an external RTC,when the PButton is pressed, save the variable data in the RTC RAM. After that have main() transfer the RTC RAM into EEPROM. Again this would test if the PButton hardware is marginal. I use RTC RAM all the time for 'setup' data and 'status' bits. It's free and fast AND battery backed up.

Hardware: Do you have any high current drawing devices? Motors, solenoids, LEDs ?? They could be the source of EMI or low power cycles.

[Drone601]

@Ttelmah -- the supply seems to be pretty solid and noise-free -- at least for the moments I've looked at it. And I don't offhand have a way of measuring the supply...unless I can (somehow?) just before a write re-jigger one of the I/O pins that shares the 5V supply to check the voltage level, then set it back...? As for the time writes, I do so once every two minutes so I don't kill the eeprom cell too soon. When I get near the 100,000 minimum guaranteed writes limit, I switch to another cell and repeat that process to get years of "guaranteed" writes. Then eventually circle back around to the first cell and take a walk on the non-guaranteed wild side.

@temtronic -- you've lost me or I've lost you. Time storage is automatic and independent of the button press. Both it and the setting storage that *is* triggered by button press that seem to be going wonky. It's that non-related-ness of the two that's making my head ache. And yes, there's a big AC motor DC-coil relays, LEDs, and other bothersome things in there.

Yesterday I tried adding a confirmation process so that whenever a write is done the next step is to read it back out and then compare that read value to the "correct" value in RAM to be sure they're the same. If not, it waits a few ms (for whatever goblin to move along) and re-writes and checks again. Repeats that a few times before giving up. Suspect it's not helping though. In fact I'm almost starting to wonder if it's not the RAM data that's going fuzzy somehow. Not sure if that's intuition or desperation.

[dluu13]

It looks like you have a FVR on your PIC. Maybe you can bring your supply voltage through a voltage divider or something into a ADC referenced to the FVR, and have your PIC dump those ADC values? I don't know how short a glitch would need to be to mess up your eeprom though, so I don't know if the ADC can be fast enough.

[newguy]

What value is your pullup resistor, /MCLR to Vdd?

[asmallri]

[Mvedovetto]