X-Mozilla-Status2: 00000000 Message-ID: <3813F06C.A4A501BC@execpc.com> Date: Mon, 25 Oct 1999 00:53:48 -0500 From: Jason Muhammad X-Mailer: Mozilla 4.5 [en]C-CCK-MCD EXECPC-45 (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Brandon Subject: Re: WDT (was: PIC Wierdness) References: <38128F0D.6ABD43BE@execpc.com> <014901bf1e8a$f90f8fd0$09255e 81@psy.unsw.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Typically, the Watch Dog Timer is used to reset a processor in the event something goes wrong. For example, it gets caught in an infinite loop (or just takes too long). The PIC processor has three methods of timing: 1) A loop with a incrementing/decrementing variable, and a check statement; 2) TMR; 3) Watch Dog Timer (with care...) The PIC has two modes for the Watch Dog Timer: Watch Dog Wake-Up and Watch Dog Reset. The Watch Dog Wake-Up is a wake up from SLEEP and a resumption of normal operation (PC + 1), whereas a Watch Dog Reset is a resetting of the part and the code starts at 0x00. The reason I used the Watch Dog Timer in the Wake-Up mode is because using the Timer the Oscillator is still running, internal or external, and uses more current. Using the WDT allows timing in SLEEP mode, which you cannot do with the Timer mode. However, timing can be off some using WDT, but my application was not very time-critical, but it was VERY current critical. I had to design a A/D application that measures high voltage yet uses less than 500uA (the majority of the time) to do it. I use 30-40uA all the time unless I have to sound the alarm, then I use 9mA three 1-second pulses a minute... Even at 32.768KHz, I managed to use only 10% of the current in WDT wake-up mode than with Timer mode. The way I utilized the CLRWDT is I set the prescaler at the beginning of the program to 288mS. Then I wrote a delay routine that causes the part to goto SLEEP and wake up in 288mS. To extend the time, I just called this delay more than once. The CLRWDT usage is very controlled...only in my DELAY subroutine, and in my calls to R/W EEPROM (just to allow a full 288mS for the R/W before reset). I actually had a problem with the EEPROM on the chip I was using and it did do a WDT RESET. That is because it took longer than 288mS to write, which is far from spec anyway. But I fixed the EEPROM subroutine... Don't worry, the Microchip techs were not very clear that this was good until they came to my job and saw the DVM with 0.02mA yet the part was working perfectly. Then they said for this particular application, it is the only way to obtain the low current consumption on a PIC part and was quite a genius exploitation of the WDT operation, still allowing the part to reset if something were to go wrong. Thomas Brandon wrote: > > 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- -- Jason ======================================== Website: http://www.execpc.com/~milsumai E-Mail: milsumai@execpc.com ICQ # : 12978762 ======================================== .:::. ,,, _(- -)_ / ( ) \ \_/ : \_/ |_/ \_| | | | -TRY PRAYER-