The 80C320 provides another useful feature to make sure your application is always running: A watchdog timer. The watchdog, effectively, makes sure your software hasn't crashed. If the watchdog determines that your software has crashed, it automatically reboots the 80C320. This is very helpful for applications that perform critical functions where crashing would cause major problems. The watchdog also offers a feature that, instead of rebooting the system, will trigger an interrupt. This is useful in situations where your software does not need to be completely reset to be "revived."
When the watchdog is enabled, the software must write to a certain SFR on a regular basis to let the watchdog know that the program is still running correctly. If the program does not perform this write within a given period of time, the watchdog assumes the program has crashed and effects a system reboot (or triggers an interrupt depending on how the watchdog has been configured).
The application may determine after what amount of time the watchdog assumes the program has crashed. The application configures the watchdog timeout value by setting
CKCON.6 and CKCON.7.
CKCON.7 is referred to as
CKCON.6 is referred to as
WD0. The following configurations determine how often the software must "kick" the watchdog to avoid a system reboot.
||Instruction Cycles for Interrupt
||Instruction Cycles for System Reboot
Note that the time in parenthesis assumes a 25Mhz crystal. Also note that the watchdog will provoke an interrupt (if so configured) 128 instruction cycles before it initiates a reset.
Thus, if WD1=0 and WD0=0 and the watchdog is enabled, your software must "kick" the watchdog at LEAST once every 32,768 instruction cycles. If your software does not kick the watchdog at least once every 32,896, the watchdog will assume your software has crashed and reboot the 80C320. How the watchdog is "kicked" is explained below.
The watchdog has a new SFR dedicated exclusively to watchdog functionality and control. The SFR is called WDCON and is at D8h. The SFR has the following component bits:
||Watchdog Interrupt. This bit is set 128 instruction cycles before the watchdog initiates a system reset.
||Watchdog Reset Has Occurred. This bit is set when a watchdog reset has occurred. If it is clear, it indicates that the last reset was not caused by the watchdog.
||Enable Watchdog Timer. The watchdog is enabled when this bit is set. The watchdog is disabled when this bit is cleared.
||Reset Watchdog Timer. Setting this bit is how the software tells the watchdog that it is still alive. This bit must be set before the watchdog timer expires.
Kicking The Watchdog
As has been explained, the watchdog will wait for the configured amount of time. If the watchdog determines that the program has crashed, it will trigger a Watchdog Interrupt (if
EWDI is set) after the configured amount of time. 128 Instruction cycles later, if the program still appears to be crashed, it will reboot the system.
In order to prevent a watchdog reboot, your software must let the watchdog know that it is still alive. It does this by executing the following code:
MOV TA,#0AAh ;Execute the Timed Access Protection
MOV TA,#55h ;code to open the Timed Access window
SETB RWT ;Reset the watchdog timer by setting the RWT bit
Setting the RWT bit (WDCON.0) is how your program lets the watchdog know that everything is ok--that your program hasnt crashed. Doing so will reset the watchdog timer.
You may be asking, "What are those first two MOV instructions for?" The
RWT bit is a "protected bit." You may not write to it without executing the two MOV instructions. Note that you must also execute those two same instructions before modifying
WDCON.0, WDCON. 1, and
WDCON.3. Please see the chapter regarding "Timed Access Protection" for a more full discussion of why this is necessary.
Using the Watchdog
In the event that the watchdog timer is not reset within the configured amount of time, the watchdog will trigger a "Watchdog Interrupt." The watchdog interrupt is a new interrupt introduced in the DS80C320.
The interrupt is enabled by setting the
EWDI bit in the new
EIE (Extended Interrupt Enable) SFR at E8h:
||Enable Watchdog Interrupt. When this bit is set, an interrupt through vector 63h will be triggered when WDCON.4 is set.
When EWDI is set, a Watchdog Interrupt will be triggered when
WDCON.3 (Watchdog Interrupt Flag) is set. The Watchdog Interrupt vector is 63h.
The Watchdog Interrupt Flag (WDCON.3) is set 128 instruction cycles prior to the watchdog initiating a reboot. However, this does not necessarily mean that your interrupt routine has 128 instruction cycles available to it.
WDCON.3 is set exactly 128 instruction cycles prior to reboot, but the Watchdog Interrupt has the lowest polling interrupt priority. If another interrupt of higher priority is executing--or if another interrupt of the same priority occurs at the same instant--the other interrupt will execute first. If the other interrupt requires more than 128 instruction cycles, your Watchdog Interrupt routine will never have a chance to execute prior to reboot.
Thus, if it is critical that your application be informed of an imminent reboot, it is suggested that you give your Watchdog Interrupt a high priority and all other interrupts a low priority. You can modify the priority of the Watchdog Interrupt by modifying the corresponding bit in the new
EIP (Extended Interrupt Priority) SFR at F8h:
Watchdog Interrupt Priority. When this bit is set, the watchdog interrupt is assigned high priority. When this bit is clear the watchdog interrupt is assigned low priority.
Watchdog System Resets
If the watchdog timer is allowed to run out and no action is taken to reset the timer in the Watchdog Interrupt, the watchdog will automatically reset the system.
A reset caused by the watchdog is like any other reset with one exception: The
WTRF bit (WDCON.2) will be set. That is to say, if WTRF is clear it means the system is booting due to some other non-watchdog related reason. If the bit is set, the boot is due to the watchdog.
You can use this information in your application to execute special code in the event a watchdog reset occurs. Take the following psuedo-code, for example:
ORG 0000hNote that if you put all your variables in Extended RAM, a watchdog reset will not erase them. Observe in the above psuedo-code that if the system is booting due to a watchdog reset, it skips the LCD and variable initialization routines. Thus, when program execution resumes at MAIN, all variables in XRAM will still be intact.
PRINT "The system locked up and was rebooted by the watchdog."
PRINT "Skipping normal device initialization."
NORMAL: LCALL INITIALIZE_LCD
MAIN: (continue normal program execution)
Programming Tip: While it is true that the 80320 will not clear XRAM on a watchdog reset, most compilers will. That is to say, the 80320 itself will not do anything to erase XRAM. However, the watchdog reset will effectively provoke a system reset. Few, if any, third party development packages check the status of the WTRF flag on startup. Thus, the system will reset and XRAM will remain intact: However, your 'C' compiler's startup code will most likely then proceed to initialize all your variables, including those stored in XRAM. If you are using a high-level language (such as 'C', Pascal, BASIC, etc.) you will most likely need to investigate how you can instruct your compiler NOT to initialize variables automatically.
However, if you are writing your program in assembler you'll have no problem: the values you've left in XRAM will be left completely intact since your assembler will only assemble the code you write--it won't include built-in variable initialization code.