The WDT appears to be one of the most misunderstood parts of a PIC (or Scenix). The basic idea of the WDT is to allow you to detect logical failure of your system and trigger a reset. The WDT is a timer that like the other timers increments every x instruction where x is the value fo the prescaler. However where other timers generate an interrupt on overflow from 0xFF (255) to 0x00 (0). Hence with a 10MHz clock and prescaler of 1:1 would increment every inst. (10MHz = 2.5MIPS = 400ns). Thus it would take 256 inst. (256 * 400 = 102.4us) to rollover. Hence, if you don't clear the WDT (with CLRWDT) every ~100us, the MCU will generate a reset. I'm not exactly sure why Jason used the WDT for his timing if he had a CLRWDT in every routine. I would have thought using TMR0 to generate an interrupt on overflow would have been easier in terms of not having to keep track of when CLRWDTswere executed. The general use of the WDT is to generate a reset when the devices enters an unknown state and thus fails to function correctly. For instance, if you have a device that is recieving serial communications, you could use the WDT to reset communications if the device lost synchronisation for a given period. In this case you could set the WDT prescaler to overflow at the maximum time without synchronisation. You would then add a CLRWDT at a point that was only executed when synchronisation was present (e.g. when the stop bit was checked indicating succesful transfer). Thus the WDT would only be reset when synchronisation was present, so if you lost sync. for more than the overflow time of the WDT, a reset would automatically be generated. Then, the reset code would have a routine to reset tyhe serial channel allowing sync to be reestablished. However, if CLRWDT's are scattered throughout the code it is difficult to do anything useful with the WDT. The main problem is if multiple routines are resetting the WDT within th e appropriate period, they must all go wrong for the reset to occur. For instance, if you added a CLRWDT to the recieving routine of the above example. Now, recieving may not be occuring but as it continues to send data a reset is never generated. Hence, care must be exercised when using a WDT to detect multiple critical failures as one section may fail but fail to create a long enough delay to generate a reset. Tom. ----- Original Message ----- From: Jason Muhammad To: Sent: Sunday, October 24, 1999 2:46 PM Subject: Re: PIC Wierdness > I recently wrote a program where ALL of my timing used the WDT. The way > I avoided my part resetting is that all my timing and EEPROM subroutines > had CLRWDT in them. Also, your prescaler will tell you how long you can > go without using the CLRWDT before your part will reset. My part used > an amazingly low 50uA. My target was < 500uA... > > Wesley Moore wrote: > > > > I recently had some unexplainable happenings whilst using a PIC and was > > wondering if anyone could shed some light on why this may have been > > happening. > > > > The circuit was essentially as follows: > > A PIC 16F84 with PORTB connected to a 7-segment display via the required > > resistors. The PIC was running at about 2.67 MHz (as checked with a CRO) > > via a RC oscillator. > > > > The software essentially just gets a character to display from a look-up > > table puts it on PORTB and then delays via a delay loop for about 600ms. > > Then it gets the next character and does the same. When the character > > returned form the look-up table is 0 it resets the count and starts > > displaying the string from the beginning. What happened was it would > > display the first 2 characters then appear to go back to the first. After > > experimenting with slower RC combinations I found that a slower clock only > > showed the first character the it blinked and it was there again. I came > > to the conclusion that it was being reset so I reprogrammed it with the > > watchdog timer off and what do you know it worked fine. > > > > Now I thought the WDT was only supposed to reset the thing when it stopped > > working, not while it was working. Can anyone explain why this was > > happening? > > > > The good thing to come out of it all is I've learnt some more and that > > will no doubt help next time. > > > > ___________________________________________ > > Wesley Moore > > RMIT - BEng/BApp.Sc. 1st Year > > > > wmoore@cs.rmit.edu.au > > http://wmoore.tsx.org/ > > -- > Jason > ======================================== > Website: http://www.execpc.com/~milsumai > E-Mail: milsumai@execpc.com > ICQ # : 12978762 > ======================================== > .:::. > ,,, > _(- -)_ > / ( ) \ > \_/ : \_/ > |_/ \_| > | | | > -TRY PRAYER-