The TI E2E™ design support forums will undergo maintenance from Sept. 28 to Oct. 2. If you need design support during this time, contact your TI representative or open a new support request with our customer support center.

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.

MSPDS: Bug in EnergyTrace current/power processing

Other Parts Discussed in Thread: ENERGYTRACE, MSPDS

In 2015 I reported an issue with EnergyTrace producing misleading power traces upon sudden drops in the measured power level. At the time I thought it was a CCS bug, so reported it in the CCS forum [1].

After looking into it again it turns out that the cause is not in CCS itself, but the emulator drivers it uses (MSPDS and XDS emupack) [2]. This has been confirmed by reproducing the issue in a standalone energytrace tool using the MSPDS driver directly, independent of CCS.

I'm reporting it here after examining the open source MSPDS driver and finding the bug that causes the misleading output.

Essentially the filtering algorithm used outputs correct current values, but associates them with the wrong timestamps. For high power situations this presents as an imperceptible phase shift. When the power level drops suddenly, however, the high reading is "held" for a significant length of time; potentially up to 1 second.

To demonstrate the problem I made a custom MSPDS driver based on the open source package v3.13.000.001. This included extra instrumentation code to run two energytrace data processors on the same input data, saving the results from each as separate CSV files. Using this, I captured the output from the original processing algorithm alongside a version I had modified to produce more accurate output.

The traces below show a capture of an MSP430G2 firmware which blinks an LED at 0.5Hz in LPM3. The hardware and firmware have been configured to give the lowest possible power consumption while the LED is off. Doing that makes the error much more noticeable.

Here's the trace as reported by the original EnergyTrace processing code:

This chart should show a square wave at 0.5Hz, but the current measurement gets "stuck" at a higher level when it should have dropped to near zero.

What's happening is that the filter algorithm waits to collect sufficient pulses from the DC-DC converter before averaging them. As it does so it keeps outputting records using the last current value that it calculated. When it eventually calculates a new current value, the timestamps it should apply to have already been reported with the previous current value.

This would be unnoticeable if the averaging were performed over a fixed length of time, but instead it is performed over a set number of DC-DC converter pulses. At very low power levels the averaging period can cover as much as 1 second. That's why the trailing edges of these pulses have been extended to such a degree.

Also notice that the initial current is reported as zero until enough input data has been processed to calculate a real value. This is why CCS often shows a minimum power/current of zero when a measurement starts off at low power.

Here's the output from my updated version:

This version of the algorithm buffers records until it has calculated their associated current value. The filtering algorithm is exactly the same as the original, but current values are reported with the timestamps of the records that were actually used to compute them.

You can see that there are still some minor inaccuracies due to the heavy filtering used, but the modified version is much closer to the true current measurement. It also correctly reports a non-zero current for the initial records.

To be clear, this demonstrates that the problem is not a fundamental inaccuracy in the EnergyTrace method or a limitation of the filtering method used. Instead it's a bug in the implementation of the filtering method.

Ideally this would be fixed by TI in both MSPDS and XDS emupack, as only the former is open source.

Additionally, I think it would be good to have a "raw output" option in the driver. This would report the DC-DC pulse counts to the application and give access to the calibration table needed to derive energy and current. With that the application would be able to filter as much or as little as needed, depending on use case.

[1] Original report in CCS forum:
[2] Recent thread with updated information:

**Attention** This is a public forum