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.
CCS6.1.0: EnergyTrace Reference profiles are plotted incorrectly
Part Number: CCSTUDIO
Tool/software: Code Composer Studio
With CCS 8.1.0, I still experiencing the issue reported at CCS6.1.0: EnergyTrace Reference profiles are plotted incorrectly.
On post Thu, Sep 10 2015 8:34 PM, Bruce Lee (SDO) filed the bug for future release.
Has the bug been fixed and released with a patch, or is it inherent to the EnergyTrace technology?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Rei VILO:
In reply to desouza:
The reason why I asked for the code is because it was unclear to me the current consumption of the time slot of 343ms was above 3mA or zero and, if you were using an example code, that would be a quick way to try to reproduce it.
However, in an ad-hoc testing I was doing with a CC2640R2F and the TMDSEMU110-ETH I accidentally found a scenario quite similar to yours: check the screenshots below.
Comparing this with the same region plotted in Excel (you can save the ET data to a .csv file) proves the bug is still outstanding (or was reintroduced at a later time).
I will check with the developer and probably file a bur report.
I apologize for the inconvenience,
I performed a new trace, took the data from the .csv file and plotted it with Excel.
It looks like the same issue is affecting the data exported to the .csv file.
Olivier, The issues are different then. Yours seem originated on the pod, while mine is originated on the display (which also matches the bug of the previous thread). By the way, the graphs showed by you indicate you are running EnergyTrace. EnergyTrace++ is only supported by selected MSP430FR devices (I know, it is a bit confusing). I will try to run this same test on the board you have - by the way, which one is it? Is it the CC1310 or CC1350? Regards, Rafael
All measures were conducted on 2 different CC1350 LaunchPads (LAUNCHXL-CC1310) + Sensors BoosterPack (BOOSTXL-SENSORS), both with an identical configuration.
Sure, the graphs posted before on this thread rely on EnergyTrace.
But I checked with EnergyTrace++ the state of the MCU and compared the EnergyTrace++ relative power graph (correct) with the EnergyTrace power graph (not correct).
As the CC1350 LaunchPads doesn't feature EnergyTrace++, I'm using the external XDS110 JTAG Debug Probe (TMDSEMU110-U).
If other tests and checks are required, please let me know.
Unfortunately I was not able to reproduce the problem in my CC1350: the graph looks ok to me when I monitor the power consumption at several locations in my trace. I am running the sensor_cc1350lp and below there is some example data:
Also, the developer pointed out the issue on my prior data capture: the image was not zoomed enough vertically to properly identify the Energy trend increase. I re-ran the previous case on my CC2640R2F and was able to display something more consistent.
I will see if I can find a scenario where the Energy graph is "broken", but at this point I am unsure what may be happening in your setup.
I reported the same bug in this thread: https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/448872/1622952#1622952
The problem only arises when the power consumption drops from a high to a very low level. In my test case the low power state is approximately 3uW.
Here's a small example program to reproduce the issue, it's for the MSP430G2 launchpad:
/* stop watchdog timer */
WDTCTL = WDTPW | WDTHOLD;
/* Switch ACLK to VLO */
BCSCTL3 = LFXT1S_2;
/* Set all GPIO to input with pulldown resistor (except P1.3, which is HiZ due to the external pullup) */
P1OUT = 0x00;
P1REN = ~BIT3;
P2SEL = 0x00;
P2OUT = 0x00;
P2REN = 0xFF;
P3OUT = 0x00;
P3REN = 0xFF;
/* Switch one LED on (P1.0) and set the other LED (P1.6) to TimerA output */
P1REN &= ~(BIT0 | BIT6);
P1DIR |= (BIT0 | BIT6);
P1OUT |= BIT0;
P1SEL |= BIT6;
/* Set TimerB to toggle TB3.1 at ~0.5Hz */
TA0CCR0 = 11000;
TA0CCTL1 = OUTMOD_4;
TA0CCR1 = 5500;
TA0CTL = TASSEL_1 | MC_1 | TACLR;
/* Enter LPM3 */
All it does is blink one LED at 0.5Hz and switches the other on. The chip is configured for low power consumption by terminating all the other inputs appropriately.
For the clearest reproduction of the issue, remove the TXD, RXD, SBWTCK and SBWTDIO jumpers from the G2 launchpad after programming. Then run a standalone EnergyTrace session (no JTAG debug connection). You can do this directly with the MSP-EXP430G2ET, or use another EnergyTrace launchpad to power the MSP430G2553 target. If you use a second launchpad you need to disconnect the targets on both boards from their emulators to avoid excess power consumption that will break the test.
First capture an EnergyTrace with neither LED jumper in place. That will show the power consumption of just the MCU. I get around 30uJ for a 10s capture.
Next capture with both LED jumpers in place. The power and energy graphs will match up as you would expect. The power graph will toggle at around 0.5Hz with 50% duty cycle.
Finally, remove the jumper for the always-on LED and capture again. Now the power graph should be incorrect, showing high power where it should have dropped to the lower level. Here's an example of a bad trace. You can see that the steps in the power graph aren't aligned with corresponding changes on the energy graph. Also, the erroneous parts of the Power trace are a lot smoother than the correct parts (note the change at around 2s)
Please find attached the trace log and the related Excel file.
You'll see the lack of consistency between Energy and Current.
Again, I'm using the XDS110 JTAG Debug Probe TMDSEMU110-U.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.