Troubleshoting WDT Resets

[NovoNate]

Hello,

We are developing a product that uses a PSoC 6 (CY8C6347FMI-BLD53 to be exact) and we are encountering resets caused by the WDT firing (presumably because our code is hanging somewhere). We have the WDT configured to fire after 5000ms and the software is setup to kick the WDT every 1000ms.

Other processors we have used in the past have had a "WDT warning" interrupt that fires a short period of time before the actual reset occurs that we implemented an ISR for that would grab the contents of the stack in an attempt to narrow down what part of the code was possibly hanging and causing the WDT to fire. Unfortunately the PSoC 6 doesn't appear to have this functionality, instead the WDT interrupt just fires when there is a "counter match" and then it resets on the 3rd consecutive interrupt.

We have tried to implement some code to catch the WDT interrupt and keep track of how long it has been between interrupts to emulate what the WDT peripheral does, but this is not working reliably enough to allow for determining what is causing the WDT to fire.

Are there any suggested ways to narrow down what is causing the WDT resets to occur?

[Len_CONSULTRON · Accepted solution]

NovoNate,

Debugging the root cause for a Watchdog trigger can be complicated as you already noted.

Here is a technique I used on another CPU that had no WDT interrupt to find the source of the WDT trigger.

1. Disable the WDT.
2. Create an ISR connected to a 32-bit timer with a very large period.  The timer emulates the timing of the WDT trigger.  Use a smaller compare value for the emulated WDT time.  Use the Period to trigger the Terminal Count output.
3. Connect the Terminal count output to a GPIO for monitoring later.
4. at the very beginning of the ISR code , read the timer value.
5. In the code when to 'pet' the watchdog, reset the WDT emulating timer.  This should emulate the WDT petting.
6. Run your code under the debugger with ONLY one breakpoint.  Set the breakpoint at the entry of the WDT emulation ISR after the point of reading the timer value.
7. If you enter the WDT emulation ISR at the breakpoint.  Look at the stack calls.   Check where the code was prior to entering the ISR.
8. Look at the timer value read.   If the timer value is too much past the expected value then something has disabled interrupts too long.  Check if it's a global interrupt disable or a local interrupt disable.
9. If you don't trigger the ISR breakpoint, check for the Terminal count output on a scope.  If you're receiving this your interrupts are probably turned off.

These steps can usually lead to enough information to provide a reasonable code review by minimizing the root causes.

Another trick I use is to place 'framing' pulses.  These are strategically placed GPIO pin writes to monitor on a scope or logic analyzer.  I place the GPIO writes to signal that the part of the code has been entered (write to'1') and exited (write to '0).   

You can use with trick with the normal WDT or the emulated WDT enabled.

One thing to note:  The PSoC6 has an WDT interrupt available if you enable it.