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.

CC2642R: firmware behaves differently when device is powered reset

Part Number: CC2642R
Other Parts Discussed in Thread: LAUNCHXL-CC26X2R1


I am using the cc2642 for multiple projects now and i have an issue where the device behaves weirdly when repowered down and up again.

I am using GPtimers to open/close some pins that are connected to external bridge, when i connect the debugger and flash the firmware the device works perfectly, the timers are very precise and everything works as intended, however when I restart the device after that by the power switch, the timers just go crazy and the precision is lost. 

is this Initialization related ? gel file ? and if so, do i need to write the procedures to initialize the device?

Jameel Magzal

  • Hi Jameel,

    Can you please share your SDK version and how you are initializing the GP Timers?  Do you have any logic analyzer or oscilloscope to validate your findings?  Are you using a TI LaunchPad or custom PCB?  What amount of precision are you expecting and how much error is introduced?  Have you tried using the Timer TI Driver instead?  Please note that the active JTAG connection could allow for a more accurate clocking than when it is disconnected, and the GPTimer clock is dependent on the MCU system clock. If very high-accuracy outputs are needed, the application should request using the external HF crystal.  Further resources are provided below: 


  • Hi Ryan,

    thank you for the quick reply, I am using simplelink_cc13x2_26x2_sdk_5_20_00_52, I am initializing the timers this way 

    posPhaseTimerParams.width = GPT_CONFIG_16BIT;
    posPhaseTimerParams.mode = GPT_MODE_ONESHOT_UP;
    posPhaseTimerParams.debugStallMode = GPTimerCC26XX_DEBUG_STALL_OFF;
    posPhaseTimerHandle = GPTimerCC26XX_open(CC26X2R1F_GPTIMER0A, &posPhaseTimerParams);

    I have 7 of these, running up to CC26X2R1F_GPTIMER3A

    and I set the load value like this

    GPTimerCC26XX_Value LoadVal_per1microsec = freq.lo / 1000000; // clock cycles per 1 micro second 
    GP_Val = (LoadVal_per1microsec) * (80) - 1; 
    GPTimerCC26XX_setLoadValue(posPhaseTimerHandle, GP_Val);

    using custom PCB,  trying to get 80 ,microseconds minimum with +- 20% max, while connected with the Jtag, i get 86 microseconds, without it, it just jumps between 100 us and 140 (should note that if I remove the jtag after flashing the firmware it still works fine, the problem is introduced when the device is turned on after shutdown.

    the application does request using the external HF crystal by using  Power_setDependency(PowerCC26XX_XOSC_HF) at the start of the task function.

    I am using oscilloscope  

  • Thank you for the additional information.  The code appears to be correct and I am further interested in your custom PCB.  How is the device powered on after shutdown (battery, external power supply, etc.)?  Does the same behavior occur after a software reset (toggling the RST line)?  Have you monitored the HF crystal startup stability?  Also, can you re-create this behavior on a LAUNCHXL-CC26X2R1?


  • Hi Ryan,

    The device is powered by a battery, 3.7 Volts 

    I will have to check toggling the reset line and see what behavior I get, as well as the startup stability of the HF crystal 

    I don't have a LAUNCHXL-CC26X2R1 at the moment to test it. 

  • Try testing with a dedicated power supply as well, or using the debugger voltage source if not the battery.  It is also worth reviewing SWRA495.


  • After reset still the same behavior

    I want to understand why after removing the debugger first time the device works fine, does this mean the accuracy is not affected by the jtag lines ? 

    power supply shows the same issue, tested it on multiple boards as well same behavior.

    what is the main difference between loading the firmware using jtag and turning the device off and on ?

  • When the device is programmed and removed from the programmer, the JTAG power stays on. Additionally, this will prevent the device from entering standby/shutdown modes.  The high-speed clock is turned off in these low-power states, thus please make sure that your Power Manager does not allow for standby mode to be entered if you want to use the GPTimer.


  • Thank you Ryan, disabling power saving solved the issue

    Best regards,