View previous topic :: View next topic |
Author |
Message |
Drone601
Joined: 16 Jan 2019 Posts: 8
|
eeprom data corruption (?) |
Posted: Tue Jul 23, 2019 9:58 am |
|
|
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
Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia
|
Re: eeprom data corruption (?) |
Posted: Tue Jul 23, 2019 10:05 am |
|
|
Drone601 wrote: | 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? |
A common issue is not having a BOR (Brown Out Rest) enabled. When the power is removed and the power rail decreases, without a BOR set, the PIC can crash as the supply rail falls. When this happens the PIC can start executing random parts of the code including the ability to write to EEPROM. The BOR will hold the PIC in reset preventing this problem. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Drone601
Joined: 16 Jan 2019 Posts: 8
|
|
Posted: Tue Jul 23, 2019 10:38 am |
|
|
Thanks for the reply Andrew.
I'm afraid I do have BOR enabled. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9244 Location: Greensville,Ontario
|
|
Posted: Tue Jul 23, 2019 12:02 pm |
|
|
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
Joined: 11 Mar 2010 Posts: 19541
|
|
Posted: Wed Jul 24, 2019 12:57 am |
|
|
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
Joined: 01 Jul 2010 Posts: 9244 Location: Greensville,Ontario
|
|
Posted: Wed Jul 24, 2019 4:52 am |
|
|
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
Joined: 16 Jan 2019 Posts: 8
|
|
Posted: Thu Jul 25, 2019 1:59 pm |
|
|
@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
Joined: 28 Sep 2018 Posts: 395 Location: Toronto, ON
|
|
Posted: Thu Jul 25, 2019 2:11 pm |
|
|
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
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Thu Jul 25, 2019 2:21 pm |
|
|
What value is your pullup resistor, /MCLR to Vdd? |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia
|
|
Posted: Thu Jul 25, 2019 2:25 pm |
|
|
Drone601 wrote: | 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. |
Is the button press an interrupt driven process or a polled process? If it is interrupt driven, are you attempting to write to the EEPROM in the interrupt handler? _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Mvedovetto
Joined: 17 Aug 2007 Posts: 38
|
Re: eeprom data corruption (?) |
Posted: Fri Feb 10, 2023 4:56 am |
|
|
asmallri wrote: | A common issue is not having a BOR (Brown Out Rest) enabled. When the power is removed and the power rail decreases, without a BOR set, the PIC can crash as the supply rail falls. When this happens the PIC can start executing random parts of the code including the ability to write to EEPROM. The BOR will hold the PIC in reset preventing this problem. |
This solved a problem in PIC16F18323: with NOBROWNOUT fuse and BORV24, internal user EEPROM went corrupted after 50-60 times of restarting, with BROWNOUT enabled no more problem!
Really great forum! |
|
|
|