Compiler/TM4C1294KCPDT: Watchdog interrupt is getting executed repeatedly, once it is timedout

Hello,

One might read MCU datasheet how to change the watchdog behavior as not to reset MCU on second timeout. Disable POR can lead to damaged hardware in high voltage systems. 

Tivaware easy commands:

/* Unlock both Watchdogs other registers for write access
 * and for performing the configuration */
MAP_WatchdogUnlock(WATCHDOG0_BASE | WATCHDOG1_BASE);

MAP_WatchdogResetDisable(WATCHDOG0_BASE | WATCHDOG1_BASE);

/* Lock both Watchdogs registers blocking write access */
MAP_WatchdogLock(WATCHDOG0_BASE | WATCHDOG1_BASE);

Hi BP101,

Thanks for your valuable time to share your points.

But I would like to clarify that my intention is not to change the following behavior of resetting MCU on second timeout. i.e my requirement is also such that MCU has to reset on second timeout,  if the cause of timeout is not yet removed, which can be achieved at ease.

The question is how to prevent the repeated execution of WDT interrupt handler, till the next time-out(could be board reset also depending on WDT Reset mode),  once it is serviced. Do we have any such provision in tivaware WDT driver library?

Regards,

Sangeeth

You have to reload the watch dong timeout register value in a function you call from inside the watched function before it expires. Sometimes you have to call it more than once or pass a value to extend the timeout period you have previously set.

Perhaps check watchdog example project on how that can be done.

Sangeeth Francis

The question is, "How to prevent the repeated execution of WDT interrupt handler"

The Peripheral Driver User Guide   'SW-TM4C-DRL-UG-2.1.4.178.pdf'   well illustrates that which you seek.    Have you located &  (recently) reviewed it?

Some 'hints' follow:

• API function 'WatchdogIntClear()' serves to, 'Clear the Watchdog Timer Interrupt.'     Note that this call must be placed 'high/early' in your interrupt handler - so that this handler is not re-entered.   (This appears to 'FIT' the issue you've described - yet 'further details' (may) be required.)
• Should you 'deploy the Watchdog' (WDG) you must create a strategy which regularly 'Clears the WDG' prior to its, 'Timing Out.'   Depending upon your program's design - you may have to emplace (several) 'WDG Clear functions' - at 'several strategic locations' (w/in your code) - depending upon your code's 'order & direction' of code sequencing.

In a nutshell - your code must 'visit' (one) of your 'WDG Clear' function calls - prior to the WDG's Timeout!     If and when the code misbehaves - the 'WDG Clear' is likely to be 'missed' - and (then) the MCU is (properly) Reset...    Is this now (more) clear?

Hi cb1_mobile,

Thanks for your reply.

We have already tried the suggestion pointed out by you,  before the post is being made.  But the observation was as follows:

1) Since WatchdogIntClear() is called inside the interrupt handler,  it will prevent the repeated execution of handler further. ( That's fine. This serves one of the requirement. )

2) But since WDT interrupt  is being cleared before the second timeout,  board won't reset,  though actual  cause of timeout exists still. (This won't serve the second requirement of resetting the board on second timeout). When the next interrupt comes,  it wiill be treated as though first timeout.

Hope the issue is clear.

Please suggest some ideas to tackle the second point as well.

Regards,

Sangeeth

Sangeeth Francis

But since WDT interrupt  is being cleared before the second timeout,  board won't reset,  though actual  cause of timeout exists still.

It is my belief that the Watchdog Design intends to, 'Automatically enable the MCU to 'Recover' from a System Hang.    As earlier stated - your 'Clearing of the WDG' should properly occur 'in advance of the WDG's Timeout.'    Perhaps you want to to, 'Adjust the WDG Timeout Period to be, JUST LESS than the 'Time at which the WDG generates the  MCU Reset.

As my firm employs ARM MCUs from many - I'm more than a bit rusty w/the 'fine details' your WDG requires.    Yet - as a general rule - the WDG causes an MCU Reset when it has not been, 'Serviced as the WDG Spec. dictates.'    This should enable the automatic recovery from a program hang.   Is not this insight adequate to enable you to devise a solution? 

Hi cb1_mobile,

Thanks for the reply.

I understood your following point.

i.e one has to clear the watchdog in advance of the WDOG's timeout, if every thing is working fine.

[We have a dedicated task for the same which periodically monitors other tasks and clears the interrupt, if everything is okay.]

But my doubt is : for example, one of the task has got stuck in between. Monitoring task identifies it and skips the clearing of watchdog hereafter, so that the interrupt hits in its timeout. But if we are clearing the interrupt inside its handler(to prevent the repeated execution of handler), will it cause the board to reset in the second timeout(identifying itself as second timeout) or just an interrupt is again generated(treating itself as first timeout, since first timeout interrupt has already been cleared).

Excerpts from Tivaware peripheral driver library is given below, which makes me to doubt whether clearing of interrupt inside its handler(to avoid the repetitive execution of handler) will allow the board to reset thereafter :

The watchdog timer can be configured to generate an interrupt to the processor after its first timeout, and to generate a reset signal after its second timeout. The watchdog timer module generates the first timeout signal when the 32-bit counter reaches the zero state after being enabled; enabling the counter also enables the watchdog timer interrupt. After the first timeout event, the 32-bit counter is reloaded with the value of the watchdog timer load register, and the timer resumes counting down from that value. If the timer counts down to its zero state again before the first timeout interrupt is cleared, and the reset signal has been enabled, the watchdog timer asserts its reset signal to the system. If the interrupt is cleared before the 32-bit counter reaches its second timeout, the 32-bit counter is loaded with the value in the load register, and counting resumes from that value. If the load register is written with a new value while the watchdog timer counter is counting, then the counter is loaded with the new value and continues counting.

Hope the problem is more clear now.

Regards,

Sangeeth

Greetings - your most recent post is the 'most clear & effort laden' of (all) those earlier.    (It is always unsettling to learn - 'After the fact' (i.e. due to 'unpresented facts') - that posters have 'implemented our suggestions.'    That's a 'time & effort' waster - is it not?)

To your doubt - 'Might you accept that an 'MCU HANG Condition' should prove capable of, 'Preventing BOTH the 1st and 2nd Clearing of the WDG Interrupt?'

Again - the 'theory' behind the WDG's Operation is, 'Any MCU irregularity - which prevents the clearing of the WDG Interrupt within TWO WDG Timeout Periods - will indeed cause (the proper & expected) 'Reset of the MCU.'

Now you appear 'hung' on the 'desire to achieve the WDG Clear, 'After WDG Timeout #1 - yet Prior to WDG Timeout #2!'   My group has seen that method employed - yet it 'suffers from' potentially 'bothersome WDG Interrupts' AND the 'Reduction in time remaining for the (required) WDG Clear - prior to Timeout #2!

It is 'Your Responsibility' to devise a, 'WDG Clearing Strategy' which insures that the WDG is:

• (optionally) 'Cleared Prior to WDG Timeout #1'
• yet (always) 'Cleared Prior to WDG Timeout #2'

and in both cases such occurs (only) when, 'All is Well' (i.e. the MCU has escaped the dreaded, 'HANG!'    Have we not  (now) - EXHAUSTED this issue?

Do note that a similar, 'VERIFY WDG' (i.e. this post RESOLVED 'your' Issue) surely warrants your (proper) Click of this Post (NOW - prior to its timeout...)

cb1_mobile

Now you appear 'hung' on the 'desire to achieve the WDG Clear, 'After WDG Timeout #1 - yet Prior to WDG Timeout #2!'   My group has seen that method employed - yet it 'suffers from' potentially 'bothersome WDG Interrupts' AND the 'Reduction in time remaining for the (required) WDG Clear - prior to Timeout #2!

It is 'Your Responsibility' to devise a, 'WDG Clearing Strategy' which insures that the WDG is:

• (optionally) 'Cleared Prior to WDG Timeout #1'
• yet (always) 'Cleared Prior to WDG Timeout #2'

and in both cases such occurs (only) when, 'All is Well' (i.e. the MCU has escaped the dreaded, 'HANG!'    Have we not  (now) - EXHAUSTED this issue?

Sorry cb1_mobile. I didn't really understand it fully. Are you suggesting an option other than WatchdogIntClear(), inside the interrupt handler, to clear the interrupt(during timeouts) thereby preventing the repetitive execution of handler by the first timeout itself. If not, i.e if you are still suggesting to use the WatchdogIntClear(), won't it prevent the board reset as I mentioned in earlier posts.

As you mentioned, we already have a logic to clear the WDG either in its first or second timeout, if the MCU has escaped the dreaded condition with in this time.

Regards,

Sangeeth

I don't know how to, 'Better present my belief.'     No need to express sorrow - I 'have tried' - not all efforts prove successful...