• Resolved

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

Prodigy 100 points

Replies: 15

Views: 257

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

  • Guru 40955 points

    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);
    

     

  • In reply to BP101:

    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

  • Guru 40955 points

    In reply to Sangeeth Francis:

    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.

  • In reply to Sangeeth Francis:

    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?

  • In reply to cb1_mobile:

    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

  • In reply to Sangeeth Francis:

    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? 

  • In reply to cb1_mobile:

    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

  • In reply to Sangeeth Francis:

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

  • In reply to cb1_mobile:

    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

  • In reply to Sangeeth Francis:

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