• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 1539 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.

RTOS/CC1350: Is there any reason watchdog reset would not trigger?

Craig Easdale
Expert 2170 points
Part Number: CC1350

Tool/software: TI-RTOS

I've got an application where 4 tasks run in parallel, (based upon the WSN example): nodeTask, nodeRadioTask, SensorTask, ErrorHandlerTask.

My error handler task contains error handling/storing functions, the watchdog timer, and the clock to clear the watchdog, which seems to mostly work quite well. I'm able to log these errors and fix the source of them one by one. However, occasionally there will be an error that causes the device to crash but will not trigger the watchdog reset. These issues are so rare that it's near impossible to catch them while connected by debugger.

My best guess is that a single task is failing for some reason, but not badly enough to cause the whole RTOS to crash which would stop the WDT clearing by the clock.

Am I correct in my assumption here? If so, is there anything I can do to ensure when a single task crashes it is either restarted or the device is reset?

Is there anything else that may cause a crash but no WDT reset?

  • 0
    TI__Mastermind 46181 points

    Craig,

    The watchdog functions in such a way that the first timeout do not trigger an reset, while the second timeout (IF the first left the watchdog un-handled) will reset the device.

    Are you calling Watchdog_clear() in a callback function? This clears the flag and prevents the second timeout from resetting the device.

    See the driver Doxygen documentation here for a more comprehensive explanation.

    BR,

    Seong

  • 0 in reply to Seong Kim
    Expert 2170 points
    Thanks for your reply.

    I may not have been very clear, sorry. I do have a clock callback to clear the watchdog. The watchdog DOES work in some situations, but I have seen a few random occasions where the device will still crash without a watchdog reset.

    What I'm concerned about is any situation that may have been a crash/stall but not triggered the watchdog.
  • 0 in reply to Craig Easdale
    TI__Mastermind 46181 points
    Craig,

    Have you tried using the ROV tool's Task Module view to debug the crashes? It would be useful to know how many tasks are failing.
    What does your task's stack size look like? If you get a stack overflow, then the OS will usually get stuck in that same task.

    BR,
    Seong
  • 0 in reply to Seong Kim
    Expert 2170 points

    From my post above:

    "occasionally there will be an error that causes the device to crash but will not trigger the watchdog reset. These issues are so rare that it's near impossible to catch them while connected by debugger"

    In short, i can't reproduce the crashes while debugging.

    In normal use the stack is well below the size allotted for each task.

  • 0 in reply to Craig Easdale
    TI__Mastermind 46181 points

    Hey Craig,

    Apologies for the late reply. I've reached out to our TI-RTOS team about your issue. I'll get back to you as soon as I hear back from them.

    BR,
    Seong

  • 0 in reply to Seong Kim
    TI__Guru* 96960 points
    Hi,

    An easy thing to try is to enable debug features in the .cfg file.

    - If you have a separate kernel project (e.g. the TI Driver examples do this)
    Use the Debug kernel project (instead of the Release) kernel project. Please refer to the SimpleLink User Guide for details on how to change the kernel project.

    - If this is a BLE example that has the .cfg in the application project,
    Please un-exclude the ble_debug.cfg file and exclude the ble_release.cfg file. Rebuild and run and you should get more information.

    - if it's neither of the above, do a differ of the debug.cfg and release.cfg files and make the corresponding changes in your .cfg. Note: the footprint will increase due to the extra debug features.

    Todd
  • 0 in reply to Craig Easdale
    TI__Mastermind 46181 points
    Hey Craig,

    We haven't heard back from you in a while, so I will close this thread. Please start a new thread for any other queries.

    Thanks,
    Seong