• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 1264 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/EK-TM4C123GXL: watchdog timer max waiting time

Javier Machuca
Prodigy 60 points
Part Number: EK-TM4C123GXL

Tool/software: Code Composer Studio

In the software i am developing i need to set a watchdog that waits about 180 seconds before attemping a reset, the system clock is running at 80 mhz using this funciton:

//Set system clock to 80Mhz
  SysCtlClockSet(SYSCTL_SYSDIV_2_5|SYSCTL_USE_PLL|SYSCTL_OSC_MAIN|SYSCTL_XTAL_16MHZ);


As i undertand the watchdog only have a 32 bit timer to set the range, limiting the waiting time to around 26 seconds with the 12.5 ns period, is there any way to set the waiting time to around 180 seconds? maybe by changing the clock source of the watchdog? or making it use a larger timer (wtimer?) or maybe the only way is reseting the timer in different sections of the code?

*edit: did a silly mistake with the time calculation, but the question remains.

  • 0
    TI__Guru**** 463981 points
    Hello,

    I will move this question to the TM4 forum. The experts there can help you best.

    Thanks
    ki
  • 0
    Guru 117855 points

    Javier Machuca said:
    need to set a watchdog that waits about 180 seconds before attempting a reset

    My friend - 180 seconds (3 minutes) seems like an (extremely LONG time) to run w/out WDG over-sight.  (Much damage could be done in those 180 seconds - isn't that true?)

    There are vendor examples which model proper WDT software & functioning...

  • 0
    TI__Guru**** 244400 points
    Hello Javier,

    Watchdog timer-0 works on System Clock which at 80MHz gives 53 seconds of count time (and not 26 seconds)

    Watchdog timer-1 works on 16MHz PIOSC which gives 268 seconds of count time.

    The next important thing to note, is that the watchdog resets the device if and only-if the last timeout is not cleared. So in effect the range of the count is doubled till the point of reset.

    Lastly if there is a change in the time calculation, you ought to correct it in the post.....
  • 0 in reply to Amit Ashara
    Guru 117855 points
    Hi Amit,

    May we ask if you'd comment upon a THREE MINUTE passage of time "unsupervised" by watchdog? (we're told that (even) Homer Simpson finds such long duration (unchecked) uncomfortable...)
  • 0 in reply to cb1_mobile
    Prodigy 60 points
    in the application i am developing i only need to upload data to a server every 30 seconds, and it doens't hurt to loose a few data points since it needs to run 24x7 for long periods of time, i understand that i could "feed the dog" in different parts of my code in an attemp to reduce the posible downtime, but if i can manage a longer than 30 seconds watchdog i will only need to do it once and it would not have too much influence in the data.
    And lastly the software currently runs without problem for days sometimes and then hangs for unknown (currently to me) reasons, so if i can manage to reset and lose only 3 minute data it shouldn't be a problem, at least until i can identify what is causing the loops.
  • 0 in reply to Javier Machuca
    Guru 117855 points

    I commend you for that analysis & quick response. Yet - with a higher frequency watchdog rate - could you not "tease out" more (i.e. (some)) troubleshooting data?   For example - at each/every WDG period you could increment all those code section (variables) which ran w/success. The advantage here is the potential to "test" a more limited number of code blocks - so that your ability to identify (failing or troubled) blocks/sections is heightened...

    Such is suggested by KISS - (smaller and faster executing) areas of focus most always reveal "issues" w/greater clarity than, "kitchen sink" (code entirety).   (which is aided/abetted by overly LONG WDG period)