![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
evsource
Joined: 21 Nov 2006 Posts: 129
|
18F2520 brownout restart_cause: brownout fuse not set?? |
Posted: Fri Apr 27, 2007 3:02 pm |
|
|
I've got some weird stuff going on with a circuit I'm working on - when I connect a PWM'ed fan on the CCP2 output, funny stuff starts happening - the chip resets over and over.
So I threw in a restart_cause switch statement, and found that it was a brownout. I put the scopemeter on the supply line to the chip to monitor the voltage, expecting to see it dipping, but it's solid as a rock.
So I disabled the brownout detect fuse, and tried it again, expecting to see that restart cause go away (and possibly the restart altogether). But nope, it's still restarting, and still has brownout as the cause.
Any ideas what might be going on here, i.e. why it's restarting with brownout as the cause, when it's not browning out and the brownout fuse isn't even set?? |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Fri Apr 27, 2007 3:55 pm |
|
|
As an added comment, look at what the chip's ground rail is doing. Unless your scope goes to exactly the same point, a voltage being induced on this, can trigger the brownout, while the Vdd, remains stable...
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
evsource
Joined: 21 Nov 2006 Posts: 129
|
|
Posted: Fri Apr 27, 2007 4:02 pm |
|
|
Ttelmah wrote: | As an added comment, look at what the chip's ground rail is doing. Unless your scope goes to exactly the same point, a voltage being induced on this, can trigger the brownout, while the Vdd, remains stable...
Best Wishes |
Thanks for the comments on the noise. That is certainly helpful.
But the big question still remains - why is it restarting due to a brownout when I:
1) Can't see any major problems on the power or ground rail (at least not enough to trigger the 2V brownout condition set on the chip)
2) Have the brownout fuse turned off!
What else would cause a brownout restart condition if the brownout fuse is not set? |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Apr 27, 2007 4:04 pm |
|
|
What is your compiler version ? |
|
![](templates/subSilver/images/spacer.gif) |
evsource
Joined: 21 Nov 2006 Posts: 129
|
|
Posted: Fri Apr 27, 2007 5:23 pm |
|
|
PCM programmer wrote: | What is your compiler version ? |
4.030, PCH (So I guess you won't be answering that PCM programmer! ) |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Sat Apr 28, 2007 7:01 am |
|
|
So what fuse keywords, are you using?.
I have just tested a dead 'minimum' program for this chip, using this compiler version. Once compiled, loaded the output file into MPLAB, and the fuses are correctly set:
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV20 //Brownout reset at 2.0V
MPLAB, shows the fuses as:
Browout detect, disabled in hardware, SBOREN disabled
I'd wonder about something though. Detecting the brownout, required the code to set the BOR bit, since otherwise the bit can start 'low', and it will not then be possible to detect the brownout. The compiler normally does this automatically, when the brownout detection is enabled, but may well not perform this if BOR is disabled. If this is the case, then effectively this bit becomes 'unusable', when BOR is disabled. If this is the case, then it would become impossible to distinguish a BOR, from a MCLR reset. The MCLR reset, leaves all these bits 'unchanged', so if the BOR bit was set, and had not been cleared, the code could not tell the two reset types apart!...
Try this:
#bit BOR=0xFD0.0
Then after your test for the restart cause, add the line:
BOR=1;
You may find that the restart cause seen, changes.
Two other resets, can leave all these bits unchanged (the stack overflow ones). It might be worth testing the status of the STKFUL, and STKUNF bits.
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
|