18F2520 brownout restart_cause: brownout fuse not set??

[evsource]

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??

[PCM programmer]

See this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=29994

[Ttelmah]

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

[evsource]

[PCM programmer]

What is your compiler version ?

[evsource]

[Ttelmah]

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