This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Part Number: TM4C1294KCPDT

Tool/software: TI C/C++ Compiler

Hi,

I'm using TM4C1294KCPDT controller with TI RTOS 2.16.

I would like to know, whether is there any provision to execute the interrupt handler only once, rather that it is being executed continuously, once it is serviced.

My intention is to allow the monitoring task to clear the WDT interrupt, if the cause for timeout is removed before its second timeout, where it is being configured for board reset.

Since the interrupt handler is being executed repeatedly, it is not allowing the monitoring task to get executed and hence board is getting reset, though cause is removed.

Any help is appreciated.

Regards,

Sangeeth

  • 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 said:
    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 said:
    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 said:

    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...

  • cb1_mobile said:

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

    Sorry to disappoint you. But really I don't understand your point Or is my question still not clear? I can make it general then.

    What can we do to execute the handler, only once, when the interrupt occurs, rather than being clearing it, so that  next time, handler will be executed , only if the interrupt is raised again.

    Regards,

    Sangeeth

  • Is it okay to use WatchdogIntUnregister(), instead of WatchdogIntClear()?

    Description in Tivaware peripheral driver library is as follows:

    This function does the actual unregistering of the interrupt handler. This function clears the handler to be called when a watchdog timer interrupt occurs. This function also masks off the interrupt in the interrupt controller so that the interrupt handler no longer is called.

     

    Regards,

    Sangeeth

  • My group does NOT believe that proves wise.

    I've taken a superior tack - presented a 'General Method' of 'Resolving WDG Issues  WHILE  enabling optimum performance - see the new posting.   (linked below)

    Especially READ & COMPLY w/the 'last paragraph w/in the PDL Section of that post.   ***  WatchdogIntClear()  description - it is (likely) that your 'Servicing of this interrupt is 'improper' - and the interrupt becomes 'entered time & again.'   

    The tactics I've listed - if thoughtfully considered - should aid you to resolve this issue.

    You should present your WDG Interrupt Service Handler as well - your 'doubts' are 'NO MATCH' for the 'hard facts' - which will then REVEAL...

    https://e2e.ti.com/support/microcontrollers/other/f/908/t/857531

  • Hello Sangeeth,

    Sangeeth Francis said:
    Is it okay to use WatchdogIntUnregister(), instead of WatchdogIntClear()?

    No, the WatchdogIntUnregister API would disassociate your ISR function from the Watchdog ISR. What would happen then is the interrupt would still fire, and without an ISR registered, it would go to the IntDefaultHandler and get stuck in the infinite loop.

    Regarding the issue itself, I don't think there is a good solution for this. The best idea I have right now would be to set a flag with the first interrupt and then use that to track if the next entry is a second interrupt. The question there would be how to intelligently clear the flag, and that would be too application specific for me to make suggestions on.

  • Hi Ralph Jacobi,

    Thanks for your reply.

    My intention was to call WatchdogIntUnregister() inside handler, which will then be re-registered inside the monitoring task, if required. (Or Use Hwi_disableInterrupt() and Hwi_enableInterrupt() respectively )

    But understood now that in both cases, if the monitoring task itself gets blocked, we can do nothing though interrupt fires, as the ISR is not registered or enabled.

     

    Regards,

    Sangeeth