Catch why a watchdog reset occurred

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
D_Sd_3235936
Level 4
Level 4
25 sign-ins 50 questions asked 25 replies posted

Hi,

My device running PSOC 4 (cortex M0) is resetting suddenly the reason is a watchdog reset.

I would like to know the last commands it ran before the reset, and where it got stuck.

Can it be done using creator?

Thanks

0 Likes
1 Solution
ScottA_91
Employee
Employee
10 solutions authored 100 replies posted 50 replies posted

Well, there's not a good way to do this, for the simple reason that such instrumentation of your code could make the problem disappear.  Furthermore the reset is problematic because all of the global & local variables would be reset.

As I see it, there are two basic options.  The first is to add a UART, and print at key points (including the reset).  Make sure the reset is repeatable (same point) and move your print statements around until you've locked down the section to look at.

Alternatively, you can replace the WDT with a regular timer and an interrupt.  Reset the timer anytime you feed the WDT and set a break point in the interrupt code.  When the timer fires, step out, of the interrupt and you should see what code was running at the time.

I'm sure there are other ways to do something similar, heck you could just disable the WDT and use break to see what's running at regular intervals.  If you're not caught somewhere, then either your feeding is too infrequent or your timer is too aggressive.  (Remember a WDT should be set such that you should get multiple, preferably 5 or more, feedings before the timer expires when the code is running properly.)

View solution in original post

1 Reply
ScottA_91
Employee
Employee
10 solutions authored 100 replies posted 50 replies posted

Well, there's not a good way to do this, for the simple reason that such instrumentation of your code could make the problem disappear.  Furthermore the reset is problematic because all of the global & local variables would be reset.

As I see it, there are two basic options.  The first is to add a UART, and print at key points (including the reset).  Make sure the reset is repeatable (same point) and move your print statements around until you've locked down the section to look at.

Alternatively, you can replace the WDT with a regular timer and an interrupt.  Reset the timer anytime you feed the WDT and set a break point in the interrupt code.  When the timer fires, step out, of the interrupt and you should see what code was running at the time.

I'm sure there are other ways to do something similar, heck you could just disable the WDT and use break to see what's running at regular intervals.  If you're not caught somewhere, then either your feeding is too infrequent or your timer is too aggressive.  (Remember a WDT should be set such that you should get multiple, preferably 5 or more, feedings before the timer expires when the code is running properly.)