• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 67 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

LAUNCHXL-CC26X2R1: Watchdog does not reset

CC2652R7: Watchdog not resetting when not debugging

Liam Langedijk
Prodigy 10 points
Part Number: CC2652R7

Tool/software:

Hi,

We are using a custom board with CC2652R7. Our application uses Bluetooth, OAD and TI-RTOS, base on the ble5stack simple_peripheral_oad_on_chip tirtos7 example.

We are noticing strange behaviour with the watchdog;

Main issue is that it is not resetting our device. We are expecting code execute to begin from main.c, but it seems to just hang and never come back alive again.

Secondary issue is that we are only getting the watchdog to trigger an attempted reset at all when a debugger is plugged in. Without debugger, our board is continuing happily well past the watchdog timeout, even without any watchdog_clear calls.

Some more detail:

Our application remains awake for x seconds before going into sleep state. While it is awake we are kicking the WD with a watchdog_clear(). We are able to make the WD trigger here by removing the kicks. But it does not reset the device as we expect, it is just hanging (debugger shows 'no symbols are defined' when we reconnect, just like this post).

Watchdog params:

// initialise the watchdog
Watchdog_init();
Watchdog_Params_init(&m_hal_stateWatchdogParams);
m_hal_stateWatchdogParams.resetMode = Watchdog_RESET_ON;
m_hal_stateWatchdogParams.callbackFxn = (Watchdog_Callback)hal_stateWatchdogCallback;
m_hal_stateWatchdogParams.debugStallMode = Watchdog_DEBUG_STALL_ON;

Second issue more detail:

We have a watchdog callback function. Inside this function we are incrementing an 8-bit counter. We then compare to see if the counter is > 20. If it is NOT >20 then we clear the watchdog and wait for the next callback. If it is >20 then we want the watchdog reset to be triggered so we do nothing and the watchdog should handle the rest for us.

The issue we see here is this; when stepping through with debugger the counter is reaching 20 and then the next callback the board loses connection (great, watchdog has worked). BUT: if we resume and let is run with no breakpoints, then we can occasionally jump in and see the value of the counter. It is reaching 20 and then getting reset back to 0 before counting up again! It is like the watchdog reset is re-initialising the counter variable but not actually causing a reset.

Do you have any ideas that might help us to progress, or knowledge that we have not picked up on?

Thank you,

Liam

  • 0
    TI__Mastermind 36750 points

    Hi Liam,

    thank you for reaching out. Taking a step back, does this issue reproduce on a launchpad? Could you also try using the unmodified watchdog example to see if the behavior is seen there as well? Which SDK version are you using?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 10 points

    Hi Jan,
    Thank you for your time looking into this.

    I have loaded the Watchdog example project from SimpleLink  7.41.00.17, and I am able to see the reset being triggered, both when debugging and using the CCS flash function to load the program.

    I still have the issue that the board is not resetting. It seems to just die and not recover. Is this specific to the CC26X2R series? I could not see this mentioned in the datasheet.

    When debugging the example project, the board loses connection, but then I am able to reconnect and the code resumes execution (In the watchdog example the LED blinks again). This is different to what I see in my project, where after a few debug steps in the HaltInBoot, it shows an address and  'no symbols are defined'.
     
    I have compared the cmd files and the only difference was the "--entry_point ResetISR" that is set in the example project, but not mine. Including this line did not change the behaviour.

  • 0 in reply to Liam Langedijk
    Prodigy 10 points

    While my initial testing didn't show me the device resetting, I think I was looking at the wrong metrics (current consumption, which didn't change). I managed to use an LED to show that I was booting from init rather than continuing code execution which made proving functionality much easier.

    The only apparent differences between example project and mine, that seemed to fixed my issue of not resetting was in the cmd linker command file :
    --entry_point ResetISR

    and

    --args 0x8

    My issue surrounding the watchdog behaving different in debug mode vs flashed are explained (I think, correct me if I am wrong) by the fact that the 48MHz clock (and therefore the watchdog clk which is derived from this) are paused when in sleep/low power mode. When the debugger is attached it keeps this clock going in order to access certain features, so the watchdog times out when in debugging in low power mode.