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.

CC2652R7: SysCtrlSystemReset not able to reset the chip and chips get stuck/bricked

Part Number: CC2652R7

Tool/software:

Hi All,

Trying to troubleshoot an odd and a very intermittent case where chips/tags just stop running - firmware just does not appear to run.

We do have watchdog implemented/added and I know it works, meaning if we don't extend the watchdog value in our code, it will reset. However, still at times we see tags that are just bricked, nothing appears to run. I am fairly certain no code is running when this happens. When we physically reset the tags by pulling the reset pin low, firmware starts right way and tag will work again.

Based on extensive debugging, we are seeing a case with SDK 7.10.01.24 and CC2652R7 chips, where when trying to reset the chip using SysCtrlSystemReset, the tags get bricked. We ran a test where we called SysCtrlSystemReset every 12 hrs, it ran for 4-5 days and then on the 10th attempt to reset (10th SysCtrlSystemReset call), tag got bricked.

Is there anything to check or measure to identify what is the state of the chip when it is in this mode? What can we do to prevent this from happening? Did anyone else experience similar behavior? Is there a better/different/recommended way to reset the chip from firmware other than SysCtrlSystemReset?

PS: In the meantime, we are running another test where before calling SysCtrlSystemReset, we added code to power down external sensors and reset cc2652R7 GPIOs such that any sensors, LEDs, buzzers, other modules the cc2652R7 is controlling, are ALL turned OFF when SysCtrlSystemReset is called. Also, cc2652R7 is receiving UART data from another MCU, we added code to stop UART data and power off the other MCU before calling SysCtrlSystemReset. I am suspecting, maybe it is power related issue of some sort and the code we added will help prevent this.

Here is the code for SysCtrlSystemReset from sys_ctrl.h:

It does have the while(1){} forever loop which kind of looks scary, it almost seems we are getting stuck in there...

__STATIC_INLINE void
SysCtrlSystemReset( void )
{
   // Disable CPU interrupts
   CPUcpsid();
   // Write reset register
   HWREGBITW( AON_PMCTL_BASE + AON_PMCTL_O_RESETCTL, AON_PMCTL_RESETCTL_SYSRESET_BITN ) = 1;
   // Finally, wait until the above write propagates
   while ( 1 ) {
      // Do nothing, just wait for the reset (and never return from here)
   }
}

  • Hello Ivan,

    I hope you are doing well. Line 7 will set the device to reset, but it will take some time to take effect so the while(1) loop is used, this is expected.

    I wanted to ask if you setup/use a Watchdog in your device/setup to reset the device if it gets stuck? 

    https://e2e.ti.com/f/1/t/1426528/

    We can use the Power_registerNotify to tell if we came out of shutdown/reset (power.h file)

    /*!
     *  @brief  Get the current transition state of the Power Manager
     *
     *  @return The current @ref Power_Transition_State.
     *
     *  @retval #Power_ACTIVE returned when no transitions are in progress.
     *
     *  @retval #Power_ENTERING_SLEEP returned during the transition to
     *  sleep, before sleep has occurred.
     *
     *  @retval #Power_EXITING_SLEEP returned after wakeup, as the device is
     *  being transitioned back to #Power_ACTIVE.
     *
     *  @sa  @ref ti_drivers_Power_Examples_transistion "Power transitions"
     */
    uint_fast16_t Power_getTransitionState(void);
     *  @retval  #Power_SOK on success.
     *
     *  @retval  #Power_EINVALIDPOINTER if either @p pNotifyObj or @p notifyFxn
     *  are NULL.
     *
     *  @sa  Power_unregisterNotify()
     *  @sa  @ref ti_drivers_Power_Examples_notify "Using power notify"
     */
    int_fast16_t Power_registerNotify(Power_NotifyObj *pNotifyObj,
                                      uint_fast16_t eventTypes,
                                      Power_NotifyFxn notifyFxn,
                                      uintptr_t clientArg);

    Thanks,
    Alex F