Watchdog timer on low voltage recovery

[RadioT]

Hello,

I have worked on and off on this since last fall with the 18F87J11, thinking I should be able to figure it out - after all, how basic can you get than a watchdog? But I have not been able to beat this problem.

I enable the WDT in the config bits and set the postscaler to some value, say 4096. These are my config bit settings:

Code: Select all

// set configuration bits at location 1FFFF8-on as described in MASM help and using names
// in Section 24 of the 18F878J11 datasheet.

// CONFIG1L Byte - DEBUG is actually debug_bar, where = 1 has debug OFF.
	Config DEBUG=OFF, XINST=OFF, STVREN=ON, WDTEN=ON //CONFIG1L 

// CONFIG1H Byte - Code protection bit only.
	Config CP0=ON //CONFIG1H = 0x04

// CONFIG2L Byte 

	Config IESO=OFF, FCMEN=OFF, FOSC=INTOSCPLL //CONFIG2L 

// CONFIG2H Byte - Watchdog timer postscale select bits, 1:32,768 when all set.
//	Config WDTPS=32768 //CONFIG2H   128 secs
//	Config WDTPS=16384 // 64 secs
//Config WDTPS=8192    // 32 secs
Config WDTPS=4096  // 16 secs

// CONFIG3L Byte - Control of the external bus - all off since this bus is part of the 80-pin device but not used in our design.
	Config WAIT=OFF, BW=8, Mode=MM, EASHFT=OFF //CONFIG3L 

// CONFIG3H Byte - Multiplex control.
	Config MSSPMSK=MSK7, PMPMX=DEFAULT, ECCPMX=DEFAULT, CCP2MX=DEFAULT //CONFIG3H 

I program the chip. I then run the application. Sure enough, if I do not command ClrWDT the WDT restarts the chip. I can tell this in my appkication because I am running an OLED display and LEDs and the device goest through the normal power up. Looks good.

Now I have a customer who insists our battery-powered device must be able to recover and restart when the internal battery goes low causing the device to halt, and when external power is reapplied, causing the chip to restart and boot up again. Seems simple, right?

But I cannot, for the life of me, get the watchdog to cause the chip to do this.

It seems the chip goes into some sort of lock-up state on low voltage. Then when the power is reapplied the device does not start. Isn't the watchdog supposed to start up automatically in it's own chip module and run when the config bits are set? Isn't it supposed to time out and cause a reset?

Note, we do not have the brownout detection set up. We were forced to use an external 2.5V regulator since we could not get the chip to go into real sleep mode unless we did that. When the internal regulator was used, everything we tried did not allow us to get the chip to go to lowest-power mode with the internal regulator in use. We checked the silicon errata, and the version of chip on the reel we bought had a bug where the LVDSTAT is not implemented.

[RKP]

RadioT,


I give a shot.

The watch dog timer will restart an already running PIC when the code is hung somewhere, waiting for something to happen that doesn't; like a blocking call.

What you need is the BOR , but since you used an external reg, this is not available.

What I believe is happening is when the battery voltage goes below the regulators dropout voltage usually the output will track the input. There will be voltage on the PIC but not high enough for it to run. Then when you apply the external voltage the PIC will still be hung.

The same thing will happen to any PIC if the power supply is brought up extremely slow the PIC will not run.

What you need is an external circuit that would toggle the MCLR line when the external supply is connected.

I hope my thoughts are helpful, if not just ignore.

Keith

[RangerBob]

In a low power situation the RC oscillator the Watchdog runs from will most likely wind up in a borked state and will not be running /able to restart when the voltage rises again. Without a clock to run from, the watchdog is useless.

As you suspect and RadioT stated, you'll probably need an external voltage supervisor if you cannot use the inbuilt BOR. Microchip, TI et al. all do Voltage Supervisors. http://ww1.microchip.com/downloads/en/D ... 51548a.pdf

[RadioT]

Thanks, guys! I will use an external supervisor in my next circuit.

ON another note, in my investigation I found that it's the bootloader that is halting the unit. I was doing everything possible in my operating code to stop the problem and then it dawned on me that there is a bootloader running first! DUH.

I love engineering, you can't BS through it

So the watchdog is now RESOLVED