• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 136 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.

CC3230SF: How to intentionally hang the system to test Watchdog reset on CC3230SF

Muhammad Afiq Zunnur Md Rahim
Prodigy 55 points
Part Number: CC3230SF
Other Parts Discussed in Thread: CC3235SF

Tool/software:

Hi TI team,

I'm currently working on a CC3230SF project using FreeRTOS. I've configured the watchdog timer in Watchdog_RESET_ON mode, and the watchdog is being cleared inside a separate task (watchdogTask). In normal operation, everything works fine and the watchdog is fed consistently.

Now I want to intentionally simulate a system hang to test if the watchdog reset mechanism functions as expected.

Here’s the issue I’m facing:

  • When I deliberately introduce a faulty call like a second initI2C() (which fails but doesn’t crash), the system doesn't hang completely — the watchdogTask still runs, and the watchdog continues to be fed.

  • So even though the main logic is unresponsive, the system never resets.

My questions:

  1. How can I intentionally hang the system (e.g., simulate deadlock, infinite blocking, peripheral stall, etc.) in a way that prevents the watchdog from being cleared?

  2. Is there any known way to cause a peripheral-induced system hang, such as forcing I2C/SPI or UART to block indefinitely?

  3. Would it be better to move the Watchdog_clear() call from a separate task into my mainThread() to more effectively catch application hangs?

  4. Are there any best practices or TI-recommended test methods to verify watchdog reset behavior?

Ultimately, I'm looking for any reliable method to force a system hang or deadlock so I can observe if the watchdog correctly resets the CC3230SF device.

Thanks in advance for your help and recommendations!

  • 0
    TI__Prodigy 560 points

    Hi Muhammand,

    Thanks for reaching out on E2E. 

    We have an example that shows Watchdog functions (both resetting the watchdog and triggering a watchdog timeout) called 'watchdog' located here 'examples\rtos\CC3235SF_LAUNCHXL\drivers'. Please take a look at this example, if you haven't already. In the case of I2C_init(), watchdogTask is still running and resetting the watchdog timer, this is why the device did not reset. When calling peripheral APIs, if there is a return value, you can check for a successful return value and if it doesn't return properly, while (1) can induce the device reset. For example:

        i2c = I2C_open(Board_I2C_TMP, &i2cParams);
    if (i2c == NULL) {
        Display_printf(display, 0, 0, "Error Initializing I2C\n");
        while (1);
    }
    else {
        Display_printf(display, 0, 0, "I2C Initialized!\n");
    }

    Above is from another example in SDK located here - examples\rtos\CC3235SF_LAUNCHXL\drivers\i2ctmp116

    TI doesn't explicitly show best practices for testing watchdog behavior, but, your approach seems to be reasonable. Watchdog_clear() doesn't need to be in the same thread as the application thread. It can be in a separate thread. Hope this helps.

    Regards,

    Santhosh