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.

CC2650 Watchdog example

Other Parts Discussed in Thread: CC2650

Hey,

I see that the MCU halts somewhere in arbitrary way so I see after pausing in debug mode that is stucks in Void Power_standbyPolicy() in CPUcpsie();!

what can be?

SO I think I should make watchdog for restarting the device in this case, where can I find an example?

Thanks.

  • Hello,

    There is a watchdog example in the 2.15 TI-RTOS release. Pleases see the porting guide on the SimpleLink GitHub page (available via BLE Wiki).

    Best wishes
  • Hello, JXS!
    It is difficult to find an appropriate example on the website you mentioned.
    Would you share exact address or "working" source code example for watchdog?
    I am using CC2650 DK2 7ID + TI RTOS 2.15 Kernel without BLE stack.

    Kind Regards,

  • Hi Jeff,

    I have one question about TI ROTS 2.15.
    I tried to find WatchdogCC26XX.c / WatchdogCC26XX.h, and also general Watchdog example in TI RTOS 2.15 version, but I couldn't.
    On the other hand, I could find WatchdogCC26XX.c / WatchdogCC26XX.h in TI RTOS 2.13 version.
    Could you kindly tell me where the TI RTOS example is?

    Best Regards,
    Ronie Oh

  • Hi,

    The watchdog driver has been removed from TI-RTOS for version that's newer than 2.14( >= 2.15 ). For now, the best way to use watchdog would be directly use driverlib if you are using the newer version of RTOS, or just use the old drivers which you can find from RTOS version 2.13.

    I would recommend to take a look at TRM chapter 15 watchdog section, or at least 15.3 watchdog initialization and configuration.

    Sorry for the inconvenience.
  • Hi Christin,

    Is there any reason to remove from TI-RTOS?

    My customer already set their environment based on TI-RTOS, and it seemed working okay.

    However, as Jeff's comment, I asked them to wait for it.

    Currently, they don't use standby mode.

    Best Regards,

    Ronie Oh

  • Hi Ronie,

    They are polishing the driver and plan to release it in June. You can port the drivers to from 2.13 to 2.15 by following this guide.
    processors.wiki.ti.com/.../TI-RTOS_Migration_2_15
  • Hi Christin,

    I already did, but just wondering why it was removed.
    Thank you for your kind reply.

    Best Regards,
    Ronie Oh
  • Hi Christin,
    Also I didn't find the WatchdogCC26XX.c / WatchdogCC26XX.h (witout installing an older version of TI RTOS) and looked at the TRM chapter 15. Very clear what to do.

    The WDT is installed and configured. When I run my program and stop calling WatchdogIntClear (), the MCU seem to reset (LED's and LCD on the SmartRF06 EB go off). It won't restart. When I press the reset button on the SmartRF06, the programs seems to start from the beginning, but the WDT won't reset anymore.

    So my questions:
    1) Why is the program not restarting after a reset? Do I need to specify a callback function in which to call a system reset?
    2) Why does the WDT only resets in the first time I run the program?

    Underneath are the functions I am calling before starting BIOS. Thanks you.

    Joris


    #include <driverlib/watchdog.h>

    static void InitWatchdog (void)
    {
    WatchdogReloadSet(WATCHDOG_RELOAD_VALUE); // Sets the watchdog timer reload value.
    WatchdogResetEnable (); // Enables the capability of the watchdog timer to issue a reset to the processor
    WatchdogEnable (); // Enables the watchdog timer
    WatchdogLock (); // Locks out write access to the watchdog timer configuration
    WatchdogIntClear ();

    if ( WatchdogRunning () )
    {
    System_printf ("Watchdog initialized\n");
    }
    else
    {
    System_printf ("{Problem initialization wachtdog\n");
    }
    System_flush ();
    }
  • Once you restart the device, if you have debugger attached or in debug mode, the device will stay in halt in boot.

    The only way to check is making sure you detach the debugger and just run the program with UART output or LED indication.
  • Ah yes indeed this was the problem. The second 'problem' was because when the debugger is not attached, the counter of the WDT is decreasing much slower than with the debugger attached. It just took a lot longer :)

    Thanks.