CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

eeprom data corruption (?)

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Drone601



Joined: 16 Jan 2019
Posts: 8

View user's profile Send private message

eeprom data corruption (?)
PostPosted: Tue Jul 23, 2019 9:58 am     Reply with quote

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: 1630
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

Re: eeprom data corruption (?)
PostPosted: Tue Jul 23, 2019 10:05 am     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Jul 23, 2019 10:38 am     Reply with quote

Thanks for the reply Andrew.

I'm afraid I do have BOR enabled.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Jul 23, 2019 12:02 pm     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Wed Jul 24, 2019 12:57 am     Reply with quote

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: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jul 24, 2019 4:52 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Jul 25, 2019 1:59 pm     Reply with quote

@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

View user's profile Send private message Visit poster's website

PostPosted: Thu Jul 25, 2019 2:11 pm     Reply with quote

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: 1899

View user's profile Send private message

PostPosted: Thu Jul 25, 2019 2:21 pm     Reply with quote

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



Joined: 12 Aug 2004
Posts: 1630
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Thu Jul 25, 2019 2:25 pm     Reply with quote

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: 28

View user's profile Send private message Send e-mail

Re: eeprom data corruption (?)
PostPosted: Fri Feb 10, 2023 4:56 am     Reply with quote

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!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group