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.

CCS/LAUNCHXL-CC1312R1: Energy Trace on custom board

Part Number: LAUNCHXL-CC1312R1
Other Parts Discussed in Thread: CC1312R, ENERGYTRACE, MSP-FET,

Tool/software: Code Composer Studio

Hi,

I was hoping to use the Energy Trace hardware on my CC1312R Launchpad to analyse the power consumption of my custom board. I am trying to run the Energy Trace in stand-alone mode without the debugger running but after clicking on the Energy Trace icon I get this pop-up:

I then get another pop-up: "Detecting Energy Trace pod..." which soon disappears and nothing happens.

I have used IAR to compile my project and so using CCS to load the hex file and symbols using a User Defined target configuration. 

I have also tried to run the Energy Trace in stand-alone mode with the pinStandby example but the same things happens. Has anyone successfully used Energy Trace to analyse their custom board with a project compiled in IAR? I would be very grateful for some help to get this running.

 I'm using CCS 9.10

Thanks,

Andy

  • Andy,

    The fact the standalone EnergyTrace session is simply vanishing is strange - the auto detection mechanism may be somehow failing. It defaults to the MSP-FET connection and, if this pod is not found, it should show the following dialog box:

    In this case, can you go to menu Window → Preferences → Code Composer Studio → Advanced Tools → EnergyTrace Technology and set the connection to XDS110? That would bypass the auto detection mechanism. 

    The code itself has no influence over a standalone EnergyTrace session - after all the pod is only measuring the current consumption of the target. 

    Just a few additional notes: disconnect all the isolating jumpers from the launchpad (the row of jumpers from GND to SWO) and use flying wires to connect the GND and 3V3 lines to the custom board. 

    Also, be mindful of the current allowance of the typical USB 2.0 connection: 500mA per port. The LAUNCHXL-CC1312R1 allows up to 400mA when using EnergyTrace HDR (the extra 100mA is to power the XDS110).

    Hope this helps,

    Rafael

  • Hi,

    Thanks for your reply. These are the default settings which I haven't seen a need to change. All jumpers are removed as you suggest and my application is such that the tx power requirement of the CC1312R is about the maximum seen as it is a low powered sensor. I am struggling for stability all round with CCS and Energy Trace even when running a program on-board with 4-wire JTAG.

    If I start in debug mode, pause randomly and click free-run, does this accurately give absolute readings still? With JTAG pins connected I am still detecting about 0.5mA of additional draw even with no debug running.

    This is my set up for clarification:

  • Andy,

    Andrew Bakin said:

    All jumpers are removed as you suggest and my application is such that the tx power requirement of the CC1312R is about the maximum seen as it is a low powered sensor. I am struggling for stability all round with CCS and Energy Trace even when running a program on-board with 4-wire JTAG.

    Interesting; you are not the first to mention instability with the latest release of CCS. Perhaps something is going on with EnergyTrace and a debug session active (I personally can't reproduce this). I will keep investigating but, in the meantime, can you try to reduce the JTAG TCLK speed of the debugger and see if the situation improves? That would only influence instabilities in a Debug Session.

    Andrew Bakin said:
    If I start in debug mode, pause randomly and click free-run, does this accurately give absolute readings still? With JTAG pins connected I am still detecting about 0.5mA of additional draw even with no debug running.

    When you are measuring at the level of hundreds of microAmps, the leakage current through the JTAG debug pins will make a difference - check the thread below that has a long discussion about such "current noise". 

    https://e2e.ti.com/support/microcontrollers/other/f/908/t/801574  

    Regards,

    Rafael