Possessed 18F1320 POR PWRT et al with bouncy unregulated supply

[NivagSwerdna]

I'm developing a gadget which is to be powered direct from a 5V supply using a 18F1320... it works perfectly when powering from the ICD3 but when away from the programmer it appears to be slightly possessed.   The circuit has just a single 3k resistor between /MCLR and VDD (i.e. none of the diode, R, C, R stuff in Figure 4-2 of the datasheet).

e.g.

Sometimes when power is applied by putting the power supply wire into a breadboard (i.e. very bouncy) it works.  But often it doesn't appear to work although power is applied to all the appropriate parts... but if you wave your fingers near sometimes it appears to be half alive.

I was wondering if the uC is actually alive from a previous attempt but in an indeterminate state but even shorting VDD and VSS before applying power doesn't make it always start.

Currently I have BOR disabled and NOPWRT but I do have WDT enabled.

I would expect that with WDT enabled that the system would correct itself with a WD reset after 8 seconds

Somehow it is getting itself into a bad state.

Any recommendations? 

[CJay]

Make sure your 'PORTB' pins are set correctly and that you're not seeing 'odd' interrupts from floating or weak pull up pins.

[jaromir]

Do you use LVP (along with LVP pin in defined state)? If not, make sure LVP is disabled.

[NivagSwerdna]

Now that I think about it might be that PGC and PGD are flapping in the breeze and that DEBUG/LVP are enabled.... that would fit with the finger effect near the ICD wire/RJ11 connector which is dangling unconnected.

[NivagSwerdna]

Do you use LVP (along with LVP pin in defined state)? If not, make sure LVP is disabled.

Yeap.  And PGM aka RB5 is floating... connected to the ICD connector only.  I'll try turning off DEBUG and LVP tonight and see what happens.   

[JPortici]

depending on how noisy the environment is, a cap from mclr to ground makes miracles

[Ian.M]

Yes.  DEBUG should *NEVER* be enabled for a release build.  The breakpoint register(s) default to having a breakpoint at address 0 enabled after reset (which is why a NOP at address 0 is recommended when debugging)  Normally this is used to let the debugger handshake with the debug executive and initialise debugging.  What happens when execution jumps to the debug vector with no debug executive is a pure gamble.  Interrupts will be disabled and peripherals are likely to be frozen and where it goes to next is anyone's guess.

With LVP enabled, a high level or floating RB5/PGM pin can cause intermittent operation, by causing the PIC to enter ICSP programming mode, which halts it and resets it on exit.

Generally you should enable BOR, and set it to the minimum for your part and enable PWRT.  Exceptions can be made if the power source switch-on and switch off are well characterised and meet the initial minimum voltage and risetime specs, or if you are using an external reset controller.  One of the known misbehaviors of the Microchip 8 bit cores when the supply voltage is out of spec is that they can 'blow through' conditional instructions and its suspected jumps etc. as well.  i.e. the program counter will continue to increment and instructions will continue to be fetched at a lower voltage than the CPU can properly execute them at.    This known misbehaviour normally shows up as random EEPROM (or FLASH) corruption after a brownout, caused by the EEPROM/FLASH write unlock sequence getting inadvertently executed.

As any code in memory may be executed, including any CLRWDT instructions present, this can defeat the watchdog.   I certainly wouldn't trust the CPU to resume normal operation correctly when the voltage rises again without a Reset signal.

[NivagSwerdna]

Disabled LVP and the demons have gone and it starts reliably.

I think I was wrong about DEBUG... I don't have that set.  It must get set when initiating a debug session and my latest builds are non-DEBUG.

Thanks all 

(I also now additionally have BOR 27 and PWRT)

[jaromir]

Glad you made it running. LVP on those older parts is classic "trap for young players".
When using MPLAB(X), the DEBUG bit is governed by IDE itself. I always leave it untouched or explicitly OFF, IDE will set it active when doing debugging and reverts back on first release programming action.