![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
Guest
|
Spurious EEPROM writing during power down..... |
Posted: Wed Feb 11, 2009 11:40 am |
|
|
Hi All,
I have a project using the 16F873A, powered at 3.3V. I use the EEPROM to store the states of a couple of switches so that these states can be recalled following a power loss. I've tested this functionality, and it works fine, or so I thought. My project is powered by a 9VDC wall wart power supply. If I unplug the wall wart from the board directly, things work fine. If, on the other hand, I leave the wall wart connected to the board, but unplug it from the wall, the switch states have (randomly) changed following power up. I'm assuming that the power loss is "fast" when I disconnect the board from the wall wart, but "gradual" when I unplug the wall wart from the wall. I suspect that the gradual power loss allows the PIC to run in an unpredictable manner just before shutting down completely?
Because I'm running at 3.3V I need to set the NOBROWNOUT fuse, so that's not a solution. Is there anything I can do to solve this problem short of using some sort of a supervisory voltage monitor chip attached to MCLR?
Thanks!
John |
|
![](templates/subSilver/images/spacer.gif) |
ECACE
Joined: 24 Jul 2006 Posts: 94
|
|
Posted: Wed Feb 11, 2009 12:49 pm |
|
|
You may need to play with the MCLR as you pointed out. Do you have the PUT enabled as well? Another option you may need to look into having a safety check before you write the values to EEPROM. ie, don't write if the voltage is below XYZ voltage. _________________ A HW Engineer 'trying' to do SW !!! Run!!! |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Wed Feb 11, 2009 10:00 pm |
|
|
Hi PCM,
Those threads seem to deal mostly with EEPROM writing that is on-going during the loss of power, which is not my situation. I'm talking about EEPROM writing that is self-initiated during the power down of my project. With this in mind, is my hypothesis a likely explanation, and will implemetation of a "more modern" PIC with programmable brownout detection make a difference?
Thanks,
John |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Feb 11, 2009 10:12 pm |
|
|
1. Are you using the "LF" version of the 16F873A ?
2. What's the oscillator frequency for the PIC ?
3. What is your compiler version ?
A better place to get information would be the Microchip forum.
Here's how to find the articles on your problem:
Go to the search page:
http://forum.microchip.com/search.aspx
In the Search Terms box, use this:
Then on the right side, select this forum:
There is a page and a half of hits. Some of the titles look promising. |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Thu Feb 12, 2009 2:51 am |
|
|
Anonymous wrote: | Hi PCM,
Those threads seem to deal mostly with EEPROM writing that is on-going during the loss of power, which is not my situation. I'm talking about EEPROM writing that is self-initiated during the power down of my project. With this in mind, is my hypothesis a likely explanation, and will implemetation of a "more modern" PIC with programmable brownout detection make a difference?
Thanks,
John |
Yes - this is almost certainly your problem. It sounds like the PIC is crashing as the voltage drops causing the spurious writes to the EEPROM. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Thu Feb 12, 2009 4:18 am |
|
|
Realistically, it should be impossible to accidentally write to the EEPROM. The hardware is quite well designed, and _requires_ the sequence of two setup bytes, latched into memory registers, to start the write operation. I have used PICs with EEPROM, since they were very first launched, and have never seen a single spurious write, in what must now be many hundreds of thousands of units.
So, you have to consider other possibilities than a pure 'spurious write'.
First question, is how is your actual 'write code' organised?. One possibility (for example), is that this routine, is being incorrectly called during some form of partial reset during the power failure. In my own code, things like the code to reset the watchdog, and the routines to write the EEPROM, are always 'wrapped'. What I do, is place a dummy return instruction, in front of them, and ensure that the routines themselves test a global bit flag, before executing, which is always cleared at the end of the routine. The main code, then sets the corresponding flag, and calls the routine. However if during a partial power failure, a random jump into memory takes place, or a code 'runaway', results in a similar jump to an unexpected location, there is no way it can get 'into' the operational part of these routines. If it is walking through code in front of them, the return is hit, and even if the call goes to the correct address, the flag won't be set.
Other possibility, how is the Vpp line wired, and/or, is the LVP fuse set, and if so, how is the enable pin for this wired. I have seen oddities on the PIC, when spikes get into the Vpp pin. This pin does not have the static protection diodes, present on the other pins, and on modern pics, the pin is only used as a reference to the programming voltage, in some cases only requiring uA to trigger programming. Because the same latches are used for programming, as are used internally to write to the EEPROM, if a tiny spike is present on the Vpp line, it does seem to affect the EEPROM, more often than the main memory, if this is where writing last took place. Similarly, if LVP is selected, noise on the enable pin for programming, can give the same result.
The final thing is are you totally 'sure', that power is not failing _during_ a write . Obviously in this circumstance, the protection latches will have been set, and if the power disappears during the operation, the result _will_ be garbage. Som form of test on the start of the write operation, for supply being in a state consistent with being able to remain 'good' for the entire duration of the write, is worth considering.
One final thing 'leaps out' at me. You refer to a 16F873A. Check this part number, and the data sheet. The minimum operating voltage for the F873A, is 4v. To operate at 3.3v, _requires_ the 16LF873A (note the extra L). EEprom writes are one of the first things to fail if you run below the specified voltage. If you have got the 'F' part, then I'm afraid this is your problem.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Thu Feb 12, 2009 11:28 am |
|
|
Hi All,
Thanks for all the suggestions! This is my first foray into running a PIC at 3.3V, and the specific issues involved were clearly something that I overlooked :-(!
I am indeed running the 16F873A (non-LF) in my design, so I guess that is the problem. When I first looked at the datasheet, the top section indicated "wide operating voltage" (2.0 - 5.5V), so I figured I was OK. Further on, however, I see that the total operating voltage range is split across the 'LF' and 'F' parts. It's still not totally clear to me what the BOR trip point is for the 'LF' part??? Perhaps BOR is not an issue if I simply use the correct part?
I think I'm just going to use the 16F883 as a replacement to take advantage of the programmable brownout selections.
BTW, I don't think that the EEPROM is truly being written in a spurious manner. I write to the EEPROM anytime a keypress is detected (input goes to GND), and I suppose the PIC responds to the voltage drop as a keypress before it stops operating?
Thanks,
John |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Thu Feb 12, 2009 2:04 pm |
|
|
Get the LF part.
Add debounce to the key detection. You really need this anyway, if detection is to be reliable. If the key is low, re-test it in a few mSec. If it is still low, then do the write. This will prevent a write during power down, and also avoid multiple detects being triggered from keybounce.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|