It is possible to use a STK or DK to measure current consumption on an external board using these simple steps.
Step 1 - Put the STK in Energy Mode 4
Use the Emode application found in Demos in Simplicity Studio to set the STK in EM4. When in EM4 the STK will ony draw a couple of nA, not interfering with your current measurement.
Step 2 - Power your target board through the STK
Connect the target board to the STK using VMCU and GND as shown in the picture below. To enable code view you must also connect the SWO pin from the STK to the SWO on your target board. Follow the instructions in the energyAware Profiler in Simplicity Studio on how to enable code view in your code.
Step 3 - Use the Energy Micro energyAware Profiler to measure current consumption and see what part of the code that uses the most energy.
What is the sample rate of the current measurement?
Most of the kits sample at 6.250khz. You can find this in the users manual for the kit in the section on AEM accuracy and performance.
For some older STK's the sample rate is lower and not listed. I don't know what the sample rate for those boards are. If you save a trace as CSV and look at the time stamps you might be able to figure it out. My vague recollection is that it's 300hz (ish).
The sampling rate on the EFM32TG-STK3300 and EFM32G8xx-STK is 100 Hz. On the DKs and STKs with black PCBs, the sample rate is 6250 Hz, as Josh said.
Useful as this tool claims to be, I don't trust it to tell me the current drawn by a target circuit. It doesn't seem to want to drop down to low power modes and pressing reset doesn't help. Even when it runs, it doesn't give that accurate results.
I've built a simple separate hardware micro-ammeter which I've calibrated and it does not agree with the figures I get from the energyAware profiler. Personally I wouldn't use it unless it's for code that will run on a starter kit. I would certainly cross check the results with an external ammeter before believing the results.
I am trying to profile a custom target (a EFM32GG395F1024) board using my STK3700. But the code correlation does not seem to work.
I am using the latest version of the Simplicity Studio.I made sure the code correlation works for the program running in STK and the same code is running in the target board as well and the SWO pin from my target board is is connected to the JTAG port of the STK as depicted in this article. Is there anything I am missing?
Also, How do I profile the existing program running in the STK with code correlation. When I start a new profile session, the binary gets flashed and the code correlation works. I quit the profiler and then launch it again (the same program still running in the STK), and start session with Run -> Existing Program option but this time the code correlation does not work. The program name area next to the Play button (Start Profiler Data Sampling button) says "Unkown program on EFM32 Giant Gecko Starter Kit" - Refer the attached screenshot.
I think you also need SWDIO and SWCLK. Don't remember whether it was the Cortex M debug core or the Jlink debugger who needed the debugging connection for SWO to work.
Turbo_J is correct, the additional debug signals are also required to enable code correlation of an external device through an STK (see this KB article for more detail).
Code correlation isn't possible when the "Run > Existing Program" option is used, because in that case the Profiler doesn't know what application is running on the device and therefore doesn't know which set of symbolic data to employ for the code correlation. Even though the running code had previously been written to the device (and therefore "known") by the Profiler in a previous session, after you close and reopen the Profiler, it doesn't know that the device is the same and is unmodified from the prior session.
As no one have mentioned, I'd like to remind something on current measurement via STK.
There is an offset inside the STK's, and the software (STK software) is adjusting it internally.
Here's what I do for a correct measurement. Firstly I'm loading a simple firmware on the STK MCU, which puts the MCU into EM4. The 20nA leak is not important for me. Then I put the STK in OUT mode. Then use the VMCU power supply and connect a parallel resistor which is around 680K. This way I can create an offset which is shows about 450nA constant power usage. And I drop this constant from my measurements. Your mileage can vary since we are talking very low currents here.
Don't forget, the STK is giving around 3,15 - to 3,3V from the VMCU and your target board normally could use higher or lower voltages. This would affect your actual current consumption.
Thank you very much Turbo_J and PhillipB. Connecting all the debug signals did the trick for me and the code correlation works like a charm now.
Regarding "Run > Existing program" when the debugger can attach to the existing running program on the target and identify why cant the profiler use some of the capabilities from debugger to achieve the same? may be this is an enhancement request for the Energy Profiler. This is much required in my opinion because not all of the applications are developed using Simplicity IDE for EFM32 chips. In my organization we use plain eclipse with a make build system (as we have to support multiple hardware configuration sometimes even with a different chip say 395F1024 and 990F1024 etc.,) and we don't use simplicity IDE. I was just trying to use the Energy Profiler after flashing the image using the makery build system we had built.
I actually had to recreate the whole of my code-base as individual projects within a workspace, per hardware config in SimplicityStudio to get to the point of Energy Profiling for a given hardware configuration (May be there is a better way...!)
That's great that this is possible; and a nifty, unorthodox way to use an STK. But at this point, is it the best way or the easiest? Is this primarily just to get the code correlation and recording, and without using expensive logic analyzers & oscilloscopes? There seems like a lot of setup issues getting this to work. I'm curious at what point I can justify the time investment?
What setup issues are you talking about? This is literally just one more wire (VMCU power to the target) in addition to a standard in-system debugging setup.