The MSP432 controller is a low power ARM Cortex M4.
TI Marketing Dept. say: low power, high performance.
I'm not looking for high performance. Low power is what I'm after at the moment.
Rather than just believing the hype, I'd better measure power myself.
So here I go, measuring the power consumption with a µCurrent and with EnergyTrace. And I'm comparing the values.
Spoiler warning: measured values match close to the reported ones.
What is EnergyTrace?
The first time I saw an energy trace plugin was when I road-tested the Zero Gecko.
I'm impressed by the possibility to see on-screen how much calories the controller is burning.
Most of the Geckos are able to show energy use per code function.
The Zero, lacking some of the required hardware to support that, didn't have this possibility.
That doesn't take anything away from the power of that tool. It's very useful to have insight in the power consumption of your design.
The Zero Gecko got high points from me on that RoadTest. This functionality was one of the reason for that (and also their great dev board and kick-ass IDE ).
So when I came to know that the MSP432 LaunchPad also supports this - inside Code Composer Studio - and with breakdown per subroutine* - I got excited.
The CCS module is called EnergyTrace. It will sample the current that the MSP432 eats, and display it in some neat ways:
- You can check how much time (or %) the processor spends in high and low power modes. You can trace watts consumed and energy spent.
- You can give it a battery profile, and it'll show how your firmware's energy budget fits in the accu's capacities (see what I did there?).
- And it will predict the battery life.
- It can beak down your firmware, telling how much energy is burned in each funtion - based on runtime analysis.
I used the power mode example from the MSP430 Deep Dive tutorial as firmware.
You can load this MSPWare project from the CCS Resource Explorer (Menu: View -> Resource Explorer (examples)).
I wired a µCurrent in series with the 3.3 V supply to the controller - remove J3 and connect both pins to the current input of the µCurrent
The µCurrent is put in the 1 mV/µA range. The shunt resistor is 10Ω. The burden voltage never exceeded 8 mV. We can ignore that when the supply voltage is 3.3 V.
The firmware steps through a variety of power modes.
For each of the modes, I've written down the value measured on the µCurrent, and the mean value of 5 seconds sampling in EnergyTrace.
MSP430 profile without debugging
Let's start with a somewhat clean board.
When you run the MSP432 in debug mode, it automatically consumes more energy - current rises 200 µA (and power is constant at 3.3V).
My exercise here was not to make a profil of the MSP432, but I did it anyway .
Here's the current consumption in the 14 different states of that Testbed, in µA:
|µCurrent wo debugger|
The table shows a mix of high and low power modes, some with clock slowed down. 88 µA (290 µW if you know that the supply is approx. 3.3V) was the lowest measurement.
Comparing EnergyTrace with Measured Values
Now let's see how the retrieved value compares with my measurements. These data points are taken with the debugger active.
You see that we draw 200 µA more current at each step.
But what we see in these samples is that the figures are close.
The EnergyTrace results are certainly good enough to investigate the controller's power profile in your design.
The values below are again in µA.
This isn't bad, is it? On a graph, you can see how close they are:
The EnergieTrace graph capture below is showing a multiple second sample exercise. Each peak is when I push the LaunchPad user button to switch to the next power mode.
*It's been a while since I used this word the last time - must be late 80's