Watchdog Timer ?

[Craig]

Hi I am using a Pic18F47Q10 Running at 64Mhz using the Internal Xtal.
In the config file I have left the Watchdog set to OFF (Disabled) and WDTPS = WDTPS_31 (Divider Ratio 1:65536; Software Control of WDTPS)
What I would like to ask is if I use the Watchdog Declare at the top of my Main loop, I Declare the Watchdog = True and then at the End of my
main loop I declare it False then obviously if something goes wrong in the execution of the main loop the Micro controller will reset.
A complete loop execution takes 260MS to complete a cycle.

What I need to ask is where does Les set the Timing In the Watchdog Declare, the run cycle time between the Two Declares When set to True (Watchdog ON) and then the execution time before it reached False (Watchdog OFF). How do I determine this time, so if the Main Loop execution time takes longer than say 350MS I need to reset the Micro Controller.

 
I see the 18F47Q10 has a WWDT(Windowed Watchdog Timer), Is it better to set this up or use the standard Declare?
Your help is very much appreciated.
Regards
Craig

[John Drew]

I may have misunderstood your plan Craig but it seems you might not be using the WDT correctly.
The usual method is to set the WDT On in the fuses and any period you want. From that point on you should use CLRWDT which resets the timer for the WDT.
You scatter CLRWDT around your code to ensure that the timer is reset in active sections of code.
If the PIC locks up then it will not see a CLRWDT and so the WDT times out and resets your device.
John

[Craig]

Thanks John that's what I thought but, the manual seems to contradict this as it will override the fuses set, unless this declare has
changed with all the updates to how the watchdog's are used in the newer pic's.

,-------------------------------------------------------------------------------------------------
As per Page 417 in the Positron 8 Manual.

Declare WatchDog = On or Off, or True or False, or 1, 0
The WatchDog Declare directive enables or disables the watchdog timer. It also sets the
PICmicro's Config fuses for no watchdog. In addition, it removes any ClrWdt mnemonics from
the assembled code, thus producing slightly smaller programs. The default for the compiler is
WatchDog Off, therefore, if the watchdog timer is required, then this Declare will need to be
invoked.
The WatchDog Declare can be issued multiple times within the BASIC code, enabling and
disabling the watchdog timer as and when required.
'-------------------------------------------------------------------------------------------------

Regards
Craig

[John Drew]

Hello Craig,
As they say "There's more than one way to solve a problem".

I'm usually not so worried about a few extra bytes of code. Often just one CLRWDT in the main loop solves the WDT function. I generally use fairly long counters for the WDT if any of my routines have long time intervals e.g waiting for serial input.
John

[TimB]

I have used WDT and let proton insert the CLWT when I was worried about long delays I just ran a loop. In reality I very rarely use a delay except on start up. It's all interrupt timers.

This leads me to my next method and that is to not use an internal WDT. I have a counter in my interrupt routine and if it counts up to X it issues a RESET. To prevent it counting that Hi I have clear it in my main loop. I set the counter to reset at around 2 seconds. My main loop will do that every 10us in most cases as the actual Code time something is happening is very short.

[joesaliba]

I have a counter in my interrupt routine and if it counts up to X it issues a RESET.

Tim,

With RESET you mean like the PIC was switched OFF, then ON? If yes, how do you issue a RESET?

Thanks

Joe

[trastikata]

With RESET you mean like the PIC was switched OFF, then ON? If yes, how do you issue a RESET?

Joe,

there's a RESET instruction by which the program counter is loaded with the value of 0 by the hardware, causing program execution to begin at address 0.

@TimB

Tim, there's one hypothetical situation where this might not work -if for some reason the program is stuck within an interrupt of the same priority as the timer is.

[Stephen Moss]

What I need to ask is where does Les set the Timing In the Watchdog Declare

I don't deleive he does set the time, AFAIK the commands just sets/clears the Watchdog time fuse to turn the WatchDog timer On/Off.

Thus the duration will be determined by the instruction clock frequency multiplied by the number of ticks until it overflows (256 or 65536), plus any augementation by any the selected WatchDog pre/post scaller values (where available) as normal.
Thus the onus is on you to calaculate the execution time of any particular section of code and determine whether or not you will need to either turn off the WDT or issue at least one CLRWDT instruction to prevent a reset occuring during the execution of that code.

As @John Drew stated, if you need the WDT then generally you would enable it and use CLRWTD commands to prevent resets, and may only need to disable it temporarily if there is code you do not want interrupted and the CLRWDT instruction cannot be used, i.e. long running serial comms where ti would be undesirable to miss any data as the result of an WDT reset or the code issuing the CLRWDT command.

I have not written any code to check as I always use CLRWDT instruction in my main loop and the beginning of interrupt handlers, but where the manual states that turning the WDT off will remove all CLRWDT instructions, presumably that only refers to those which lie between the instruction turning the WDT off and the next instruction turning it back on again, as removing them all would be counter productive. 

[ricardourio]

Hello,

    It's not so clear to me either. With Declare WatchDog = On I don't need to use CLRWTD in my code and the compiler will take care of it?

Ricardo Urio

[top204]

With the Declare Watchdog set to one or true, the compiler will alter its default config fuses to enable the watchdog timer. But more importantly, it will add Clrwdt mnemonics to its library subroutines so the watchdog does not trigger itself when any of the command subroutines are waiting. Especially the commands that require delays.

If you look in the assembler code produced by the compiler when the Declare Watchdog is set to one or true, a lot of Clrwdt mnemonics will be present within its library subroutines. Even where it would normally have a Nop mnemonic to delay a single clock cycle, it will have the Clrwdt mnemonic instead, and instead of a Bra $ + 1 or Bra $ + 2 or Goto $ + 1 mnemonic to delay 2 clock cycles, it will have Nop, Clrwdt instead for the 2 cycle delay, to make sure the watchdog is reset.

However, it does not add any Clrwdt mnemonics in the main user's code, except in low value DelayUs and all DelayCs commands that would normally use Nop, because they are created as inline delays, so a loop of any kind must clear the watchdog before entering it, or clear it within it, if it does not use any high level compiler commands that clear the watchdog timer.

The compiler understands assembler mnemonics in the high level parser, so the Clrwdt mnemonc can be added as a BASIC command in your code.

[joesaliba]

Joe,

there's a RESET instruction by which the program counter is loaded with the value of 0 by the hardware, causing program execution to begin at address 0.

Thanks Trastikata.

Joe

[Craig]

Thanks Very much for all the feed back and help John,Tim,Joe,trastikata,Stephen,Ricardo and for the detailed explanation Les.
Regards
Craig

[John Drew]

Because a reset causes a program counter to be set to zero the values of variables are left untouched, so if a variable has a value that caused the lockup then the watchdog will cycle.
If I've got that right, what should be done to recover?
Maybe clear all variables, maybe reload defaults at the start of the program?
John

[joesaliba]

Because a reset causes a program counter to be set to zero the values of variables are left untouched, so if a variable has a value that caused the lockup then the watchdog will cycle.
If I've got that right, what should be done to recover?
Maybe clear all variables, maybe reload defaults at the start of the program?
John

Well, usually I always give a variable a value, so that should not be a problem for me.

Joe

[trastikata]

If I've got that right, what should be done to recover?

I always issue a Clear command somewhere at the beginning but the WD should not kick-in during the normal program operation anyway, wherever I have a loop I try to foresee any stall situations.

It is rather for unexpected events without timeouts that could stall the program execution - usually IMO for communication protocols or in noisy environments where the program counter may jump to incorrect address. 

[gtvpic]

The watchdog is very appreciated by me. It is not only about your program being well executed without any closed loop, interference can also cause the program to get lost.

The watchdog's function is to recharge the timer before the count ends. If the count ends, the processor restarts and the program starts again.

I think it is vital to have a watchdog that verifies that given a certain time the program recharges the time and everything is working correctly.

Great forum and very useful