Microcontroller Energy Profiling/EFM32 STKs are cheap right now

[alexwhittemore]

Really I'm mashing two topics into one here but I'm sure interested to get your take. One is energy debugging, one is cheap EFM32 STKs on Mouser.

I'm a bit down a rabbit hole of system energy profiling for small microcontroller products right now. For representative example: a WIFI sensor that sleeps at 500nA, wakes up after a timeout, reads a sensor, connects to wifi to exfil data (300mA bursts), then goes back to sleep. This typically takes something like 7 seconds, and if you're not interested in doing the calc, that's ~116dB of dynamic range.

Options I know of include:

• uCurrent
• Low Power Labs CurrentRanger
• Atmel atpowerdebugger
• Advanced Energy Monitor on EFM32 STKs
• Low Power Labs CurrentRanger

I'm pretty sure there are some expensive probes that support this task as well, but I can't find them so maybe not. EDIT: I was thinking there was a J-Link product, but I don't think there is after looking. What I was definitely thinking of is Lauterbach tools.

The uCurrent really isn't suitable unless you just want to spot-check static functionality. Put your product in sleep mode and measure a point, put your product in all-LEDs-blaizing mode and measure a point, so on.

The CurrentRanger is awesome because it auto-ranges fast enough to get good dynamic data without browning-out the DUT, but it doesn't (in the factory firmware) support hardware indication of what range it's in - it just shows you an LED. I do expect, before too long, I'll use some of the spare IOs to do just that, so I can set up a MATH trace something like "output (amps) = (A1*D1*1e-9)+(A1*D2*1e-6)+(A1*D3*1e-3)"

But neither of these correlate the in-time data to, say, a stack trace showing what function i'm in. Both of the next two options do that:

The Atmel atpowerdebugger (https://www.digikey.com/products/en?mpart=ATPOWERDEBUGGER&v=150) is basically a $190 Atmel-ICE (typ. $130) that has current measurement built-in, and tools in Atmel Studio to measure that current. Additionally, the debugger portion of it is CMSIS-DAP compliant, so it should, in theory, work with any old Cortex-M target you want to use, not necessarily only Atmel parts. It's got 1 channel that's high-res at 100mA full scale, and one that's lower-res at 1A full scale. Not sure if you can use both simultaneously to, say, separate your power domains and measure the high-burners separate from the sleep-mode-sippers, all at once. I haven't finished reading the user guide yet to figure out if it supports the trace-aware time correlation that the next option does.

The EFM32 STKs from SiLabs have an "Advanced Energy Monitor," which is basically a 0.1uA to 50mA current measurement channel integrated with an embedded J-Link debugger, such that you can correlate current consumption with your stack trace. Pretty neat! What's extra-rad is that every STK on SiLabs' website is currently listed at $89 or $99, but Mouser has all of the older "EFM32xG-STK3x00" series STK boards for $30. Here's the GiantGecko 3700 board, for example. The newer boards with newer parts and more interesting peripherals included are still in the $100 range. I wonder if SiLabs hiked the price of all STKs with the new releases and Mouser has old stock? Unfortunately, because the embedded debugger is an EFM32-locked Segger J-Link, there's not much hope of using the board to trace+power-debug a non-EFM32 external target. But if you don't mind missing out on the trace data, you can hook up whatever old device you want to the AEM side and measure only that. $30 seems like an excellent deal for a high dynamic range current profiler with pretty good software behind it. Especially if you're already working with EFM32 parts.

If you're the type of person who's had to do embedded power profiling before, what does your toolbox look like?

[lucazader]

The recently announced (on kickstarter) Joulescope is probably perfect for what you want here.

[alexwhittemore]

The recently announced (on kickstarter) Joulescope is probably perfect for what you want here.

Oh sweet jesus my wallet. You're right - it's nearly perfect, and completely out of my pricerange  . I suppose I'll have to get a client to buy it for me next time such becomes a high priority.

One thing it does leave out is any correlation to operation - with something like a CurrentRanger+Analog Discovery, you could have GPIO or printf-style (UART decode) program state indication - you see "C" on UART followed by a burst, and you know that burst was WIFI connection. You see a "S" and you know you're entering sleep mode, etc. Or of course, if you have one of these first-party options from SiLabs or Atmel, you could use your program counter trace to do about the same.

I'd love to see some kind of support on the Joulescope for input like that, maybe a bit more precise than a timestamp in this app matched up to a timestamp from UART, etc. Just some way to overlay markers onto the current trace.

EDIT: the Kickstarter page hasn't been updated, but it's in the updates - I'm not the first person to ask about it, and exactly this request will be in the production version: https://www.kickstarter.com/projects/jetperch/joulescope-precision-dc-energy-analyzer/posts/2427774

Ugh now I have 64 hours to find $500 laying under a couch cushion.

[Styno]

A bit late reaction, but maybe it helps others searching for low power consumption monitoring:

Texas Instruments sells cheap LaunchPad development boards with EnergyTrace or EnergyTrace++ that, in combination with their IDE Code Composer Studio (CCS) allow for detailed low power profiling (sub-uA to several tens of mA). You don't need to use an MSP430 or MSP432 in your project for this to work, just grab a LaunchPad that features EneryTrace(++) and use it to power your own board.

Learn more about this:
Blog:
https://43oh.com/2015/09/how-to-measure-an-energia-applications-power-usage-with-energytrace/

Video:

Pipe power consumption data to Excel/GnuPlot: https://43oh.com/2017/03/pipe-energytrace-data-to-gnuplot/

Cheapest LaunchPad with EnergyTrace for €10,--

[alexwhittemore]

Better late than never! This task isn't going away anytime soon, so I appreciate the addition! EnergyTrace looks like an excellent addition to the ecosystem along the lines of atpowerdebugger and Advanced Energy Monitor. Seems like maybe I'll have to get my hands on all three and do a shootout, especially since I think all three are now supported by decent general-purpose toolchains like PlatformIO that are probably a little less of a hassle to get up and running with a blinky.

Looking back at the Joulescope again, man, it really seems like the hands-down winner for grab-and-go usability, but yeah, I'll sure need to justify that $700 before I pick one up. Maybe if I come across a very constrained "analyze our power profile" client project

[ogden]

Two cents of actual experience: in case you have control over firmware, you may find long term energy consumption figures (thus battery capacity) using analytical approach. Craft two firmware versions 1) always sleeping 2) always consuming, measure average consumption for each state. Let firmware accumulate power statistics itself - measure total runtime of sleep & consumption states. All you need for that is hardware timer and few additional CPU cycles for each power state change. "Accelerated time" firmware may be useful as well. For instance if your "thing" have sleep/run duty cycle 10000:1, run it 100x times faster, at 100:1 duty cycle - you will drain "4-year battery" in 15 days. Knowing self-discharge of the battery, you can estimate battery lifetime quite accurately.

[edit] In short: fancy power monitors are not that good for power monitoring and power budget estimation. They are useful for power profiling, hunting inefficient code.

[alexwhittemore]

That certainly seems like a good strategy for total consumption measurement.

I guess, yeah, power profiling is the thing I'm primarily interested in. For instance, the project that sparked the conversation is a wifi sensor that wakes up, connects, sends an image, sleeps. Without direct profiling, we wouldn't have realized that it's the wifi connection phase, not the image size, that really determines the bulk of the wake-cycle energy consumption (of course, everyone "knows" that's why wifi is bad for battery. But "knowing" isn't the same as "understanding"). Without profiling over a lot of cycles in a lot of environments, or as you say, mounting an accelerated full-drain campaign, we wouldn't have figured out EXACTLY how variable that connection phase is depending on site specifics. In a home, close to a router, it'd reliably take ~2s from sleep to IP. In a business environment with lots of devices and towards the edge of a given router, it might take anywhere from the 2s best case to a 10s worst case - which is a LOT of variability on total battery life if that's your biggest energy drain.

So I guess - both have their place, and they're probably not actually even interchangeable.

I'll keep that in my toolkit for next time profiling tells me the numbers I expect to see.

[ogden]

For instance, the project that sparked the conversation is a wifi sensor that wakes up, connects, sends an image, sleeps. Without direct profiling, we wouldn't have realized that it's the wifi connection phase, not the image size, that really determines the bulk of the wake-cycle energy consumption (of course, everyone "knows" that's why wifi is bad for battery.

To measure that, you do not need power probe with 120dB dynamic range. Scope and current shunt resistor is enough.

[alexwhittemore]

It's true - if you're only measuring the active phase, such high resolution isn't necessary. The high dynamic range is much more useful when measuring the sleep current - and in fact, not just MEASURING, because the same would apply, but more actively optimizing or fiddling, when it *might* be nanoamps or it *might* be mA or it *might* be somewhere in between, depending on whether you've set all your peripherals and switches right. During such a phase, constantly change a range switch or swapping measurement setup just to load firmware and repeat is a bit of a pain.

At the end of the day, as you aptly point out, it's not so much a question of what you CAN do, because there's always more to trade to get the job done with what you've got. It's a question of how easy you can make life for how little investment of dollars and hours.

[eddie1]

Looking back at the Joulescope again, man, it really seems like the hands-down winner for grab-and-go usability, but yeah, I'll sure need to justify that $700 before I pick one up. Maybe if I come across a very constrained "analyze our power profile" client project

It is indeed awesome! (The EFM32 STK AEM is awesome too, *especially* for its price point, but I wanted a wider voltage range and bought the Joulescope for that.)

[eddie1]

At least some of the Atmel/Microchip SAM Xplained Pro boards include the "Xplained Pro Analog Module" for current measurement. I just noticed it while looking at the SAM L10 Xplained manual; see section 3.2 for details on the capabilities. It doesn't explicitly say you can measure an external target, but since there are jumpers to connect the onboard MCU power pins to either the onboard regulator directly or the measured output, I would guess you could connect anything. The L10 Xplained board is about $60, cheaper than the $190 of the ATpowerdebugger (though I'm not sure how the measurement capabilities compare). There might be other cheaper Xplained boards with this capability; I didn't look.

Also, while the EFM32 STK deal mentioned in the original post is long dead, the EFM8 starter kits appear to include the AEM and are still $30. (Why are the EFM32 boards so damn expensive?)

And there's also the Nordic Power Profiler.

[charlesrg]

The MSP430FR4133 is very tempting, given that there are ways to read the data without the TI Code Studio, however the limitaion on 3.6V only is a problem. There are times that we still want to test 5V stuff.