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.

SIMPLELINK-CC13X2-26X2-SDK: EnergyTrace++ Reliability

Part Number: SIMPLELINK-CC13X2-26X2-SDK
Other Parts Discussed in Thread: ENERGYTRACE

Hi everyone,

I have been trying EnergyTrace on the CC1352R1 launchpads, initially I've followed this guide: 

Using EnergyTrace on standalone mode works well, ALTHOUGH I had to use the instructions of jumper configuration shown on figure 34 of page 28 of this guide: as well as a board power cycle after any jumper modification for current recalibration. Both jumper configuration and board power cycle are NOT MENTIONED on the first guide, which led me to a lot of completely different measurements and battery estimations using exactly the same code and settings, which I had absolutely no idea why, until I read the second guide.. So I think this info should be added on the first guide.

Now, using the EnergyTrace++ is when most problems appear, it is almost unusable. After starting the debug session, most of the times the debugging just fails, or works for a few seconds and then fails. Sometimes it works but with periods without EnnergyTrace data. I keep getting the -261 error code, either IcePick_C or CS_DAP_0, bellow is a printscreen of the console during the EnergyTrace++ debug session. I have searched around on E2E forums, but it seems to be kind of an unknow communication issue, I've tried changing USB ports, USB cables, not using any HUBs, it still always happen. Only thing I haven't tried is using a different PC. I'm on a windows 10 machine, with CCS V10.4.0.00006. I'm running the TI15.4 stack sensor/collector default demo without any changes except the disabled broadcasts (dwell time 0).  

Sometimes I am able to get a complete 1 minute session, although it still has moments where the -261 error occurred and for that reason, no data seems to be available for those moments, but fortunately the system recovered from the errors and was able to continue the session. Most of the times this is not the case, as the debug sessions just stops, or the EnergyTrace windows just crashes and disappears from the debug environment.

Bellow is an image with both the EnergyTrace++ states and current measurements together from the same test, on a sensor device with the default TI15.4 stack demo (with no broadcasts/dwell time 0). 

But even in these rare occasions where I get a complete session, I wonder about the reliability of these results. For instance, on the states graph, after the rejoining process happens (around the 26/27s mark) there seems to be a lot of activity (as expected since the default demo has 3s report interval, 2s poll interval and 5s tracking intervals), however, most of these activities are showing only RX activities and almost no TX, except near the end of the graph.

So my questions are:

1 - Why aren't all the supposed TX activities showing on the states graph? 

2 - How reliable is the EnergyTrace++?

3 - What can I do to stop or minimize the -261 errors during the EnergyTrace++ debug session? Because it is almost impossible to use like this.

Thanks for your time,


  • Hi Joao,

    Please refer to the EnergyTrace section of the TI 15.4-Stack User's Guide as well as the EnergyTrace manual.  Have you configured the CC1352R1 target for cJTAG (1149.7) 4-pin standard mode?  Please be sure to use the shortest USB cable available.  Are you able to reliably use EnergyTrace with a TI Drivers example?


  • Hi Ryan,

    I've followed both those manuals, and like I said, I also followed the "Measuring CC13xx and CC26xx current consumption" application report (SWRA478D) which has important information that both the other 2 guides don't have (and should be added by the way like pinout config and power cycle to recalibrate the xds110). I did change the target for cJTAG 4pin mode, and used all sorts of different short cables I had available. Nothing made a difference.

    I just tried a couple of different demos from TI Drivers like you suggested. The EnergyTrace++ debug session seems to be slightly more stable than before, but still has plenty of -261 errors and still crashes most of the times.

    Thank you,


  • João,

    Unfortunately this is a very elusive error that has escaped our radar for many years - it is also reported in the Debugging JTAG page.

    At this point we unfortunately do not have a clear solution to that. In my observations this seems to be related to the data bandwidth between the Debug Probe and CCS, thus one thing that might help is to close the other views (Memory, Disassembly, Registers/Variables) and any real-time data updates to allow higher bandwidth for the EnergyTrace data capture.

    I apologize, I wish I had a more definitive solution for that.

    Best regards,


  • Hi Rafael,

    I've been in that page already, so yeah, that's what I was expecting unfortunately. Thanks anyway.

    Regarding the missing TX plots on the state graph, is there something you can tell me? Is it normal for the states graph to miss certain RF events? For example, there should be a TX plot every 3s, since the report interval is 3s, but most of the events only show RX activities. How reliable are those RF activities indicated on the states graph?

    Thank you,


  • Hi Joao, 

    Unfortunately, I am sure about why the Tx events are missing from the plots. I could not find any specific documentation regarding RF states on the energy trace++.
    But an alternate way of getting the Tx, Rx events can be found in the debugging RF output section of the debugging guide.

    Maybe this would be helpful to map the Tx and Rx activity more accurately. 


  • Hi Siddanth,

    Ok thanks, it seemed unreliable to use the EnergyTrace++ for checking the RF states. I just wanted to be sure. 

    There is a lot of documentation for TI15.4 Stack and the Energy Trace but there's also a lot missing in terms of details.