Energy Profiler

Simplicity Studio® 5 (SSv5)'s Energy Profiler enables you to visualize the energy consumption of individual devices, multiple devices on one target system, or a network of interacting wireless devices to analyze and improve the power performance of these systems. Real-time information on current consumption is correlated with the program counter providing advanced energy software monitoring capabilities. It also provides a basic level of integration with the Network Analyzer network analysis tool.

Energy saving and efficiency are at the top of developers’ priorities for an ever-growing number of embedded systems applications. These constraints can be due to government regulations (for example, metering applications), a requirement to increase battery life, or simply a need to lower the electricity bill. In battery-operated systems, energy efficiency often plays the most important role. In cases where developers are satisfied with their system’s battery life, increasing the energy efficiency means they can switch to a smaller and cheaper battery, which will lower the overall cost. There are also situations where the operating life must be extended to the absolute maximum, such as products where the battery cannot be replaced or replacement involves very high costs.

Having a low-power MCU by itself does not mean you will have lower energy consumption. The trick is to optimize your software not just in terms of functionality, but also with respect to energy efficiency. Having full control of the hardware surrounding the MCU and optimizing the overall software and peripheral usage are crucial factors for reducing system energy consumption. Software is not usually seen as an energy drain, yet every clock cycle consumes energy. Minimizing the number of clock cycles becomes a key challenge to reduce overall system consumption.

The Energy Profiler enables you to visualize the energy consumption of individual devices, multiple devices on one target system, or a network of interacting wireless devices to analyze and improve the power performance of these systems. Real-time information on current consumption is correlated with the program counter providing advanced energy software monitoring capabilities. It also provides a basic level of integration with the Network Analyzer network analysis tool.

In these pages the following terms will be used:

AEM: Advanced Energy Monitor

ISD: The file extension used with Multi-Node Energy Profiler and Network Analyzer files.

PTI: Packet Trace Information

Starting an Energy Analysis Session

An energy analysis session can be started from either the Simplicity IDE Perspective or from the Energy Profiler Perspective.

From the Simplicity IDE Perspective

Some Silicon Labs SDKs contain examples that are pre-configured to deliver energy profiling data to the Energy Profiler. In the Simplicity Studio Launcher perspective, you can find example titles such as "Powertest" or "Energy modes" or "Emode" for many development kits. In the figure below, the selected device is an EFR32 development kit. The Flex SDK has been installed.

Create an example (in this case Flex(RAIL) - Energy Mode). Because this is a RAIL example, the Simplicity IDE perspective opens with the Radio Configurator open. If this is an AppBuilder project, click Generate.

Right-click the project directory. In the context menu select Profile As > Simplicity Energy Profiler Target.

SSv5 then:

  1. Rebuilds the entire project.
  2. Flashes the application to compatible hardware.
  3. Starts energy capture for that device.
  4. Switches to the Energy Profiler perspective.
  5. Displays the device data on Single-Node View, Multi-Node View, and Scope View.

In step 2 above, if more than one connected device is compatible with the application being profiled, SSv5 prompts you to select a device. Select the target of interest and click OK.

After the application is built and the firmware flashed, the Energy Profiler perspective is displayed, with a release notes dialog. Click OK.

From the Energy Profiler

If application firmware is already running on a device, you can connect to it from the Energy Profiler tool. Open the Energy Profiler perspective. Click Quick Access to display its menu and select Start Energy Capture.

If more than one connected device is compatible with the application being profiled, SSv5 prompts you to select a device. Select the target of interest and click OK.

Energy Profiler then:

Customer Hardware and Software Design Information

Hardware Design

EFM8 Hardware Interface

To use the Energy Profiler functionality on a board design, the board needs to include a debug interface that can be connected to a Silicon Labs starter kit (STK) or wireless starter kit (WSTK). For the basic Energy Profiler current measurements, the board must be powered from the VAEM supply of a Silicon Labs STK or WSTK. Both the current measurement and EFM8 C2 Debug interface can be obtained by using the Silicon Labs Mini Simplicity 10 pin connector. This connector is detailed in AN958: Debugging and Programming Interfaces for Custom Designs. The EFM8 C2 interface signals are on SWDIO (Pin 7 C2D) and SWCLK (Pin 8 C2CK) pins shown in the following figure.

Code correlation is not possible with the EFM8 parts as they do not include the SWO pin that is used to transmit the program counter information. As mentioned in AN958: Debugging and Programming Interfaces for Custom Designs, using the Silicon Labs debug adapter board (BRD8010A) is the easiest way to get the Mini Simplicity pinout from a Silicon Labs STK or WSTK development kit.

EFM32 and EFR32 Hardware Interface

To use the Energy Profiler functionality on a board design, the board needs to include a debug interface that can be connected to a Silicon Labs STK or WSTK. For the basic Energy Profiler current measurements, the board must be powered from the VAEM supply of a Silicon Labs STK or WSTK. To also include code correlation, the debug interface must include the SWD interface. Both the current measurement and the code correlation (SWD) can be obtained by using the Silicon Labs Mini Simplicity 10 pin connector. This connector is detailed in AN958: Debugging and Programming Interfaces for Custom Designs. The Mini Simplicity 10 pin connector can be used with all EFM32 and EFR32 parts. The pinout is shown in the following figure.

As mentioned in AN958: Debugging and Programming Interfaces for Custom Designs, using the Silicon Labs debug adapter board (BRD8010A) is the easiest way to get the Mini Simplicity pinout from a Silicon Labs STK or WSTK development kit. The debug adapter board is not compatible with the older EFM32 Development Kits (DKs) and some of the older EFM32 starter kits (STK) that have a different debug connector on them (Gecko, Giant Gecko (EFM32GG-STK3700), Leopard Gecko, Tiny Gecko, Wonder Gecko, Zero Gecko).

Software Design

To use the current monitoring functionality provided by the AEM interface, no software changes or setup are required. To use the code correlation functionality, the SWD interface must be configured to output periodic program counter information.

EFM8 Software Configuration

Currently, code correlation is not possible with the EFM8 family. The Multi-Node Energy Profiler can still be used to monitor the overall energy use of the parts over time / usage scenarios.

EFM32 Software Configuration

  1. Add bsp_trace.c to the project. (from <SSv5 install>\developer\sdks\gecko_sdk_suite\<version>\hardware\kit\common\bsp)

  2. The macros BSP_TRACE_SWO_PIN, BSP_TRACE_SWO_PORT and BSP_TRACE_SWO_LOC must be defined. For EFM32 parts this is done by default for Silicon Labs development kits in <SSv5 install>\developer\sdks\gecko_sdk_suite\<version>\hardware\kit\<board>/hal-config-board.h. For a custom board design the Silicon Labs hal-config-board.h can be used as an example for defining the values. The following is an example for the Pearl Gecko Starter Kit (SLSTK3401A): 

      // $[GPIO]
  #define    PORTIO_GPIO_SWV_PIN                              (2)
  #define    PORTIO_GPIO_SWV_PORT                             (gpioPortF)
  #define    PORTIO_GPIO_SWV_LOC                              (0)

  #define    BSP_TRACE_SWO_PIN                                (2)
  #define    BSP_TRACE_SWO_PORT                               (gpioPortF)
  #define    BSP_TRACE_SWO_LOC                                (0)
  // [GPIO]$

  3. The code must enable SWO output from the MCU. To enable this output, add #include bsp_trace.h to main.c and call BSP_TraceProfilerSetup() during initialization after the EMU_DCDCInit() call in main().

      #include 
  #include "bsp_trace.h"
  .
  .
  .
  /* Initialize DCDC. Always start in    low-noise mode. */
  dcdcInit.dcdcMode = emuDcdcMode_LowNoise;
  EMU_DCDCInit(&dcdcInit);

  // Setup SWD for code correlation
  BSP_TraceProfilerSetup();

  4. The program must be built with debug information enabled so that source code lookup is possible. If you create your project in SSv5, this is enabled by default. If you import a project into SSv5, check compiler options in project context menu Properties... > C/C++ Build > Settings. If you build your program outside of SSv5, check compiler options of the build tools.

EFR32 Software Configuration

  1. Add bsp_trace.c to the project. (from <SSv5 install>\developer\sdks\gecko_sdk_suite\<version>\hardware\kit\common\bsp)

  2. The macros BSP_TRACE_SWO_PIN, BSP_TRACE_SWO_PORT and BSP_TRACE_SWO_LOC must be defined.

    1. With the BLE SDK this is done by default for Silicon Labs development kits in <SSv5 install>\developer\sdks\gecko_sdk_suite\<version>\hardware\kit\<board>/hal-config-board.h. For a custom board design the Silicon Labs hal-config-board.h can be used as an example for defining the values. Below is an example of these macros for a SiLabs BGM121 radio board: 

       // $[GPIO]
 #define       PORTIO_GPIO_SWV_PIN                                 (2)
 #define       PORTIO_GPIO_SWV_PORT                                      (gpioPortF)
 #define       PORTIO_GPIO_SWV_LOC                                 (0)

 #define       BSP_TRACE_SWO_PIN                                   (2)
 #define       BSP_TRACE_SWO_PORT                                        (gpioPortF)
 #define       BSP_TRACE_SWO_LOC                                   (0)
 // [GPIO]$

    2. Use the Hardware Configurator or Pin Tool to enable the GPIO module. This adds the BSP_TRACE_SWO_* macros to the hal-config.h file.

  3. The code must enable SWO output from the MCU. To enable this output, add #include bsp_trace.h to the appropriate module and call BSP_TraceProfilerSetup() during initialization as indicated in the following sections, based on the product family and SDK being used:

    1. EFR32 - BLE SDK: Place BSP_TraceProfilerSetup() in main.c after the initApp() call. 

       #include "bsp.h"
 #include "bsp_trace.h"
 .
 .
 .
 // Initialize application
 initApp();

 // Setup SWD for code correlation
 BSP_TraceProfilerSetup();

 // Initialize LEDs
 BSP_LedsInit();

    2. EFR32 - Flex SDK: Place BSP_TraceProfilerSetup() in main.c after the BSP_Init() call. 

       #include "hal_common.h"
 #include "bsp_trace.h"
 .
 .
 .
 // Initialize the BSP
 BSP_Init(BSP_INIT_BCC);

 // Setup SWD for code correlation
 BSP_TraceProfilerSetup();

    3. EFR32 - EmberZNet SDK: Place BSP_TraceProfilerSetup() in af-main-soc.c after the emberInit() call. 

       #include "afv2-bookkeeping.h"

 #if defined(CORTEXM3_EFR32_MICRO) ||  defined    (CORTEXM3_EMBER_MICRO)
   #define EXTENDED_RESET_INFO
   #include "hal/micro/cortexm3/ diagnostic.h"
 #endif
 #include "bsp_trace.h"
 .
 .
 .
 int emberAfMain (MAIN_FUNCTION_PARAMETERS)
 {
   EmberStatus status;

   {
     int returnCode;
     if (emberAfMainStartCallback(&     returnCode,      APP_FRAMEWORK_MAIN_ARGUMENTS)) {
       return returnCode;
   }
 }

 // Initialize the Ember Stack.
 status = emberInit();

 if (status != EMBER_SUCCESS) {
    emberAfCorePrintln("%pemberInit  0x%x",     "ERROR: ", status);

    // The app can choose what to do  here.      If the app is running
    // another device then it could  stay     running and report the
    // error visually for example. This  app     asserts.
    assert(false);
 } else {
    emberAfDebugPrintln("init pass");
   }
 // Setup SWD for code correlation
 BSP_TraceProfilerSetup();

  4. The program must be built with debug information enabled so that source code lookup is possible. If you create your project in SSv5, this is enabled by default. If you import a project into SSv5, check compiler options in project context menu Properties... > C/C++ Build > Settings. If you build your program outside of SSv5, check compiler options of the build tools.

Energy Profiler User Interface

The Energy Profiler perspective is divided into six primary sections. The following figure shows Single-Node view.

Three views are available for evaluating power performance:

Single-Node View

Single-Node view is used to display a single device’s waveform and events. It displays a high-detail waveform and ensures that all events rows are visible, without the need to scroll the UI. The Energy Profiler perspective combines this Single-Node view, the Code Correlation view, and the source code Editor view, allowing you to perform in-depth analysis of a single device from many viewpoints. Any active device may be selected through the Display Nodes menu.

Multi-Node View

Multi-Node view is used to display multiple device waveform and events. It allows you to investigate system behavior and interactions between devices. Two devices are visible in the main portion of the UI, while others are viewed by scrolling. The Multi-Node view groups each individual device’s waveform and events together. The Energy Profiler perspective combines this Multi-Node view, the Code Correlation view, and the source code Editor view, allowing you to perform in-depth analysis of multiple devices from many viewpoints.

Multi-Node view offers the following capabilities:

Sorting

Sorting in Multi-Node view allows you to order waveforms based upon several criteria. For example, it may be useful to sort descending by average power, such that the highest power consumers are easily identified at the top. As shown in the following figure, devices may be sorted ascending and descending by name, average current, average power, or total energy.

Displaying Nodes

Enabling capture on any device automatically adds it to the Multi-Node view. However, as the number of devices displayed increases, UI performance may be impacted. Click Display Nodes to select the devices that will be displayed. This selection only affects the waveform display. If recording is enabled, data for all actively capturing devices is streamed to disk regardless of whether or not they are displayed.

Scope View

Scope view is used to display multiple device waveforms and events, allowing you to investigate system behavior and interactions between devices. In Scope view, all waveforms are displayed in one waveform area, so that you can see all waveforms without needing to scroll the UI. It also enables the user overlay and align traces like an oscilloscope. All event traces are grouped below the waveform view. The Energy Profiler perspective combines this Scope view, the Code Correlation view, and the source code Editor view allowing you to perform in-depth analysis of a single device from many viewpoints.

Scope view offers the following capabilities:

Sorting

Sorting in Scope view allows you to order events based upon several criteria. For example, it may be useful to sort events descending by average power, such that the events for the highest power consumers are easily identified at the top.

Displaying Nodes

Enabling capture on any device automatically adds it to scope view. However, as the number of devices displayed increases, UI performance may be impacted. Click Display Nodes to select which devices will be displayed. This selection only enables or disables display of waveform and event data in the UI. If recording is enabled, data for all actively capturing devices is streamed to disk regardless of whether they are displayed.

Displaying Waveforms

One of the Scope view’s key benefits is the ability to view waveforms in a single view at difference scales, enabling you to compare waveform characteristics that would not be possible for two waveforms on the same scale. The waveform scale/offset controls are available by default at the upper right corner of the Scope waveform view. The color of the waveform scale/offset control indicates which waveform will be adjusted when the sliders are moved.

The drop-down menu at the top of the control allows you to select the device to be adjusted by the waveform scale and offset control. The debug adapter name colors match the colors in the waveform portion of Scope view.

Toggle wave scale/offset control display using the show/hide button above it.

Selecting Ranges

Energy Profiler provides the ability to select a range of data by clicking and dragging across the waveforms or events. This is useful for determining power statistics for regions of interest. Once a range is selected, a light gray section summarizing the energy statistics for the selected region is displayed. That section also allows you to re-center the selection in the waveform view if it has scrolled out of view and includes a button to close/deselect the region.

Energy Statistics

Energy Profiler calculates the following device and system statistics:

Statistics are provided for each individual device in the waveform’s top bar on both Single-Node and Multi-Node views. The sum for all devices is provided in the top bar of Multi-Node Energy Profiler for all three views. Single-Node and Multi-Node views provide individual device statistics, while Scope view does not.

Energy Statistics Configuration

Energy Profiler allows you to select which of the actively capturing devices are included in the total system energy statistics calculation displayed in the top bar. Click the Energy Statistics Configuration icon and select the devices to be included in the calculation. It is important to note that the devices available for selection are those that are actively capturing data, which may be different from the devices that are selected for display in the UI.

Energy Statistics Snapshot

Energy Profiler allows you to save statistics for future reference and comparison. Click the Save Snapshot icon on any of the energy statistics panels and be presented with a dialog to provide a name and tag for future reference.

Review Saved Statistics

Once you have saved multiple snapshots, you may want to review them, or to copy them to the clipboard for use in other applications. This is possible through the Profiler->Session Statistics... menu.

Play and Record Data Control

The following diagram provides a general description of data flow from target devices into SSv5 profiling applications. Data is sourced from target devices from the debug adapter either through USB or Ethernet connectivity to the host PC. The host debug adapter software layer provides data to the AEM/PTI data streaming engine, which in turn provides data to analysis applications such as Multi-Node Energy Profiler or Network Analyzer. The AEM/PTI data streaming engine saves data to disk in temporary files during a capture session. When the user ends the session, Energy Profiler prompts the user with the option to save the data to file.

Play and record controls in the top bar of the Energy Profiler perspective provide control over data being captured from connected devices.

Play Control

The Play control determines whether data being captured is displayed in the Multi-Node Energy Profiler UI. The Play control has three states:

Record Control

The Record control manages data streaming to disk. There are two states to the Record control:

Freeze and Record Triggers

Triggers provide a method to automate freezing the display or recording to disk. Trigger icons are found below the Play and Record controls. Three triggers are available:

Triggers are driven by criteria set by the user. To set the criteria, use the context menu available from each trigger icon. The context menu also provides the ability to clear all conditions, which also disables the trigger.

Trigger States

The four trigger states are each designated by a color:

When Energy Profiler first starts up in a new workspace, all trigger icons are grey, indicating trigger conditions have not yet been set. Clicking a grey trigger icon opens the trigger configuration dialog, allowing you to specify trigger conditions. Once trigger conditions have been set, the trigger icon turns yellow, indicating the trigger conditions are set but the trigger is not armed. Clicking a yellow trigger icon arms the trigger as indicated by the trigger icon turning red. Incoming data is now evaluated against the trigger condition. Once the trigger condition is satisfied, the trigger icon turns green, indicating the armed trigger has fired. The relevant action (freeze, record start, or record stop) will have been executed. The following diagram shows the trigger state behavior.

Freeze Trigger

The freeze trigger transitions the user interface from play to freeze mode automatically based upon search criteria. The freeze criteria are set through the Freeze Trigger Conditions dialog. This is invoked either through the Profiler > Freeze Trigger... menu selection or by right-clicking the Freeze Trigger icon and selecting **Configure Freeze Trigger".

In the following diagram, the play freeze trigger condition has occurred in the incoming data. Freeze mode is automatically entered for the waveform display and data continues to arrive as indicated by the scroll bar automatically moving to the left as new data arrives. Notice that the freeze trigger icon is green, indicating the trigger condition has occurred in arriving data.

Record Start/Stop Triggers

The record start/stop triggers automatically start and stop data record to disk based upon search criteria. This may be beneficial for capturing rare conditions rather than recording large amounts of data followed by search. The record start criteria are set through the Record Start/Stop Trigger Conditions dialog, which is invoked through the Profiler > Record Triggers... selection" menu or by right-clicking the Record Start or Record Stop icon and selecting the Configure option. The record start/stop trigger conditions are set together in a single dialog as shown in the following figure.

In the following figure, the record start trigger condition has occurred in the incoming data as indicated by the green record start trigger icon. The record stop trigger condition has not yet occurred and data will be written to disk until it does.

Search Capability

One of Energy Profiler's most powerful aspects is the ability to search data. Search is available both during a live capture and with an offline ISD file. Click Search to open the Search Conditions dialog.

When you click OK, a search is performed on all data currently available, whether from the currently active capture or in offline mode from an open file. The search results window is displayed on completion. Sections where the data matched the criteria are shown in red. A summary of the count and % coverage of the matching regions is shown at the upper right. Use the context menu to jump to the matching in the waveform view from the search results window.

Profiling with Code Correlation

Code correlation is one of the most powerful features in Energy Profiler. Energy Profiler captures program execution in conjunction with the energy data. This allows Energy Profiler to calculate the power consumed by each function executed in the application. This data may then be sorted to highlight the portions of an application that consume the most power. This enables the application developer to know where they should concentrate their software development efforts to reduce power consumption. Additionally, Energy Profiler can color-code sections of the current waveform to represent which functions were executing when a given section of the current waveform occurred.

Enabling Code Correlation

This section assumes an embedded application is already configured to produce AEM data through a debug adapter. For code correlation to operate, Energy Profiler needs access to debug information associated with the embedded application that is currently running. This information is available in the AXF file output from the build. Code correlation can be enabled when an application is started from the Simplicity IDE perspective through context menu commands for a given project, or it can be associated with an application already running on an embedded device that is being profiled in Energy Profiler.

From the Simplicity IDE Perspective

One simple way to enable the code correlation view is to start the energy profiling session by using the context menu on the project from the Simplicity IDE perspective, as shown below. The associated debug file will be provided to Energy Profiler when the session is started.

Once Energy Profiler starts, the following view is displayed. Notice in the Code Correlation view, energy consumed by each function is updated in real time. Clicking any of the functions opens the associated source code file and jumps to that function in the file.

From Energy Profiler

If you start energy capture with a running embedded application, Energy Profiler does not have the debug information it needs to associate program execution with source code. In these cases, the Code Correlation view is as shown in the following figure.

Click the elect an Executable link and the program selection dialog is displayed. Debug files from open projects are provided in the list. Alternatively, you may browse to select the debug file.

Code Correlation View

The Code Correlation view is shown below the waveform portion of the Multi-Node Energy Profiler Perspective, and works in conjunction with the Editor view. When multiple devices are displayed in the Multi-Node view, you can click on each adapter to view the function profile data associated with that device. The function data may be sorted as desired. Clicking on any function opens the associated source file in the Editor view with the start of scope for that function selected.

Color Coding and Code Correlation

Energy Profiler provides the ability to color-code the current waveform based on program execution. You can set the color for each function using the context menus in the Code Correlation view.

The following figure shows the current waveform view with several functions set to different colors.

Energy Profiler and Network Analyzer Integration

Note: This functionality is only available in offline mode with a previously saved ISD file.

Energy Profiler and Network Analyzer now provide a basic level of integration when trace data from a debug adapter includes both AEM and PTI data. This integration allows you to easily move between the two applications by selecting an event in either one and selecting Show in Network Analyzer or Show in Energy Profiler.

An SSv5 preference determines whether moving between applications leaves the Energy Profiler perspective and opens the Network Analyzer perspective, or stays in the Energy Profiler perspective.

To open a previously saved ISD file, either use the top menu Profiler > Open ISD File... menu or the Quick Access > Open ISD File... menu, as shown in the following figure.

Once the file is open, you can examine previously recorded details. In the following figure, notice two devices transmitting and receiving packets. Select a TX or RX event and display the context menu. One of the options is Show in Network Analyzer.

Select that option and the Network Analyzer view opens either in the Energy Profiler perspective or the Network Analyzer perspective, based upon the preference setting.

Likewise, you can select an event in Network Analyzer and use the context menu to navigate back to Energy Profiler.

Use Cases for Multi-Node Energy Profiler and Network Analyzer

Depending upon your goals for an analysis session, there will be times when you will primarily use Network Analyzer, times when you will primarily use Energy Profiler, and times when you will find it advantageous to use them together.

When you are interested in energy consumption of a single or multiple devices, Energy Profiler is where you will focus your time. From a network communication perspective, it provides only the start time of a TX or RX packet, and does not provide any decoding of the packets themselves. Still, this information can be revealing in your application's consumption of power relative to network activity. For example, by using the search tool, you can set search criteria that identify all points in the data where a packet was transmitted and the power exceeded a given value. If you have an expected power performance based upon your design, you can quickly identify when your system is operating outside its specification.

If you are interested in packet contents, node activity, and network interaction in a wireless network, Network Analyzer is where you will focus your time. Network Analyzer's multiple editor panes provide tiered displays of network activity, letting you drill down from a high-level map of node interactions to the details of each packet. Customizable filters enable you to specify exactly which network activities to display, allowing you to sift out information unrelated to a given task. These features allow you to determine when your network is behaving as expected, but are not available in Energy Profiler.

You will find yourself benefitting from the integration of these applications where these two information spaces intersect. For example, the Energy Profiler use case mentioned above ended at finding a transmit packet that exceeded expected power consumption. To investigate further, you could select Show in Network Analyzer to investigate that specific node's network activity and packet contents, in hopes of determining why the power was higher for that particular network transaction. In contrast, you may suspect that packets with specific content are the root cause of high power consumption. In Network Analyzer you could search for that data, and use Show in Energy Profiler to determine if indeed those packet contents are the root cause of high power consumption.

Post Analysis Using an ISD File

Both Network Analyzer and Energy Profiler capture data in the same format, which are saved in the ISD file format. Both applications can open an ISD file that has been save by either application. For example, if you have completed an Energy Profiler session and saved the ISD file, only to realize later that you are interested in the packet trace information, you would open that file from Network Analyzer to further investigate it. It is important to note, however, that captures started in Energy Profiler include packet trace data by default, but captures started in Network Analyzer only contain energy data if the preference to include it has been selected, as shown in the following figure.