Recognize and resolve Watchdog related issues while debugging

When debugging your embedded application, you may encounter issues related to the active Watchdog.

In an embedded application, the Watchdog (WDOG) or Watchdog Timer (WDT) provides a safety mechanism that allows detecting and recovering from the application malfunction by resetting the embedded microcontroller and restarting the application. If an active Watchdog is not handled properly during debugging, the application cannot be debugged successfully.

The Watchdog is typically a timer that starts counting from 0 and performs a specified action, usually a reset, when it reaches a certain timeout value. While the application behaves predictably, the Watchdog is serviced by the application periodically before the timeout hits. However, if it happens that the application goes into the weeds at some point, the Watchdog doesn’t get serviced on time, which then triggers a reset resuming the whole application from a fresh start.

During the debugging, the active watchdog has to be handled accordingly. One way is to completely disable the watchdog during the debugging but that’s not the best option since it’s no longer the same environment in which the application will run in the end.

Sometimes a watchdog itself already provides support for debugging where the internal timer gets stopped while the user application is stopped. If that’s not supported, the debugger has to provide a mechanism through which the watchdog gets serviced for the time when the user application is not running, which otherwise services and keeps the watchdog from timing out.

There are two main types of Watchdogs: Internal Watchdog and External Watchdog or System Basis Chip (SBC). The Internal Watchdog is implemented on the chip itself, typically making it easier to disable by a simple write to a register. On the other hand, the External Watchdog/SBC is implemented separately either as a separate chip or a board, and it can reset the chip or cut the power. Disabling the External Watchdog is more challenging since it operates independently from the chip.

How does it manifest when the active watchdog is not handled properly during debugging? You may notice you cannot perform a download in winIDEA, your application doesn't run as expected or error messages pop up with the content such as Chip in reset, Cannot stop the CPU, error programming, external reset detected, etc.

But don’t worry, we have a new tutorial addressing this issue.

By following a step-by-step guide, you'll learn how to handle the Watchdog whether it's an internal or external one. The Tutorial provides clear and straightforward instructions on how to troubleshoot Watchdog-related debugging problems.

Don't let the Watchdog stop you from debugging and try to keep the original application behaviour as much as possible when debugging within your development process.