Avoid a common mistake... don't schedule a interrupt driven timer task to restart the watchdog timer - it rather defeats the purpose as you *can* lose control of foreground and still service interrupts.

The main run loop is often sufficient, but not always. People usually have the greatest problem around simple monitor commands when they are letting the operator change settings. This stuff is usually slammed in at the last step with the latest updates and customer changes and often is not great looking code. A tight loop looking for a keystroke or comm character is HUMAN-TIME and your WDT will often reset while you wait looping.

Most WDT use relies upon bigger loops that include tapping the WDT during each test for data arrival. This is often repeated many times during the kludgey man-machine interface. Its ugly but works.

I use a scheduler/tasker and so I never waste time in such I/O loops. My foreground only accesses *logical* I/O in buffers/flags/images; background actually handles all the devices and pins through the tasker.

When I need a Human input, I call a task modify routine that puts the return address from the stack into a task vector. From there it continues to the other tasks in the run loop. So I never get into a hard, tight loop that requires constant WDT thumping.

When some IO from that device is moved into the buffer from the background task, it activates the scheduler task link if set and goes back to that address from the saved return address.

I'm a great believer in scheduler/tasker organization in assembly code. Its guru level stuff though.

duh