The 80C320 provides another
useful feature to make sure your application is always running:
A watchdog timer. The watchdog, effectively, makes sure your
software hasnt 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
WD1 and 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
Instruction Cycles for
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:
This bit is set 128 instruction cycles before the watchdog
initiates a system reset.
Watchdog Reset Has Ocurred.
This bit is set when a watchdog reset has occured. If it is
clear, it indicates that the last reset was not caused by
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
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
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.
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
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:
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.
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 0000h JNB WTRF,NORMAL PRINT "The system locked up
and was rebooted by the watchdog." PRINT "Skipping normal
device initialization." LJMP MAIN NORMAL: LCALL INITIALIZE_LCD
LCALL INITIALIZE_XRAM_VARIABLES MAIN: (continue normal program
Note 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.
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.