TM4C129ENCPDT: Once the watchdog expires the callbackFxn is called continually

Part Number: TM4C129ENCPDT

I am using TIRTOS 2.16.0.8.  What I am trying to do is record in a eeprom the fact that a watchdog occurred and then reset the board.

The processor has an interesting watchdog feature where it will interrupt once the count down reaches 0 and then reset the next time the count down reaches 0 if the interrupt has not been cleared.

I setup a watchdog call back function that wakes up a task that is supposed to handle writing to the eeprom.

The problem is since I can't clear the watchdog interrupt (because if I do the second expiration will not reset the board) the interrupt routine continually fires until the board resets. 

The continually firing interrupt prevents me from writing to the eeprom.

I have tried to use the TivaWare level api WatchdogIntUnregister to remove the callback function once I have kicked off my task but it generated link warnings about no section .vectors and does not resolve the problem.

Under TI-RTOS how can I prevent the rapid calls to the watchdog call back while writing to the eeprom and waiting for the reset?

  • Hi Roy,

    The problem is since I can't clear the watchdog interrupt (because if I do the second expiration will not reset the board) the interrupt routine continually fires until the board resets. 

    That is just the way the watchdog works. You must clear the interrupt to prevent from reset. If you don't clear the interrupt then the interrupt becomes pending. If will just re-enter the ISR repeatedly. This is true not just for Watchdog but for any modules generating interrupts. 

    If you want to record the watchdog reset event into the EEprom, you can read the RESC register to determine the cause of the reset event. For example, if you get a reset, read the RESC register. If the RESC indicates a watchdog reset event then write to the EEprom to record this event. Will this work?

  • I believe I should be able to mask the interrupt so it switches to  operating in a polled mode.  I simply have not been able to figure out how to mask it once it fires because the TiveWare api does not seem to be compatible with the TI-RTOS implementation.

    Your suggestion to use the RESC register could work in a limited sense but it does not really address my need.  I have the code setup to use this same mechanism to capture resets due to exceptions and extraordinary conditions such as the remote network devices I must interact with are unreachable. 

    My eeprom logging is recording more than just the total count of watchdogs.  It is counting exceptions and causes of watchdogs.  It is much cleaner to capture this information before the watchdog reset occurs. 

    I appreciate your commentary.

  • Hi,

    I simply have not been able to figure out how to mask it once it fires because the TiveWare api does not seem to be compatible with the TI-RTOS implementation

    Please see below description in the datasheet. Basically, once you enable the interrupt, you cannot disable it anymore until a reset. 

    Register 3: Watchdog Control (WDTCTL), offset 0x008
    This register is the watchdog control register. The watchdog timer can be configured to generate a
    reset signal (on second time-out) or an interrupt on time-out.
    When the watchdog interrupt has been enabled by setting the INTEN bit, all subsequent writes to
    the INTEN bit are ignored. The only mechanisms that can re-enable writes to this bit are a hardware
    reset or a software reset initiated by setting the appropriate bit in the Watchdog Timer Software
    Reset (SRWD) register.

      As I mentioned, it is a hardware behavior where you must clear the flag so the interrupt does not stay pending after it exits the ISR. There is no way around it by not clearing it. I understand once you clear the interrupt flag, it will start all over again and there will not be a reset when the watchdog times out the 2nd time. 

      The only thing I can suggest is that you clear the flag and  write your eeprom data. After your required task is complete, manually generate a software reset (by calling SysCtlReset())  to replace the desired watchdog reset that will not come. 

    [Edit] If you want to disable interrupt, you could possibly disable at the NVIC level by calling IntDisable(INT_WATCHDOG) but not at the watchdog module level.

      Also to give you a heads-up I will be out of office for the rest of the week starting tomorrow. In case no one responds to this post, you can open a new post so the moderator on duty can respond to your question.