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.

  • Resolved

CCS/CCSTUDIO: CCS8.1.0 — EnergyTrace Current and Energy Graphs Consistency

Guru 21665 points

Replies: 21

Views: 2999

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,  filed the bug for future release.

Has the bug been fixed and released with a patch, or is it inherent to the EnergyTrace technology?

Thank you!

  • Configuration includes:

    • Hardware:
      • Computer: Windows 10
      • Board: LaunchPad CC1350 (LAUNCHXL-CC1310) + Sensors BoosterPack (BOOSTXL-SENSORS)

    • Software:
      • CCS 8.1.0
      • TI-RTOS

  • Guru 142610 points

    In reply to Rei VILO:

    Hi,

    Can you share the code (or at least the example) that you used to trigger this?

    Thank you,
    Rafael

    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

  • In reply to desouza:

    The code of the whole project? I'm afraid that wouldn't be possible.

    Basically, a clock triggers a task every ten minutes. The task acquires data from sensors and send values to a base through sub-1 GHz using the EasyLink library.

    Apart from the 694 ms of activity, the LaunchPad CC1350 (LAUNCHXL-CC1310) + Sensors BoosterPack (BOOSTXL-SENSORS) remains in deep sleep mode as reported by EnergyTrace++.
  • Guru 142610 points

    In reply to Rei VILO:

    Hi,

    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,

    Rafael


    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

  • In reply to desouza:

    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.

  • Guru 142610 points

    In reply to Rei VILO:

    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


    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

  • In reply to desouza:

    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.

  • Guru 142610 points

    In reply to Rei VILO:

    Olivier,

    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. 

    Regards,

    Rafael


    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

  • In reply to desouza:

    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:

    #include <msp430.h> 
    
    void main()
    {
        /* 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 */
        __bis_SR_register(LPM3_bits);
    }

    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)

  • In reply to desouza:

    Rafael:

    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.

    EnergyTrace_2018_08_10_091957.zip

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.