Energy efficiency is a critical factor in embedded system design, and OpenEPT’s Energy Debugging feature is here to revolutionize the way developers analyze power consumption. By seamlessly integrating hardware and software monitoring, OpenEPT provides real-time insights into the energy usage of embedded systems—without compromising performance. With precise energy sampling, real-time visualization, and intuitive data analysis, OpenEPT makes power profiling effortless. Whether you’re optimizing firmware, debugging energy anomalies, or comparing different implementations, this toolset empowers engineers to make informed decisions that enhance device efficiency.

This blog outline main working mechanisms behind OpenEPT’s Energy Debugging feature, breaking down its hardware interface, communication protocol, and real-time visualization capabilities. Firmware Energy Profiling Library (FEPLib), a lightweight yet powerful tool that simplifies platform integration and accelerates development across various MCU-based platforms, is described within this blog post.

The energy debugging feature, encompassing both hardware and software, within the OpenEPT system is distributed across multiple devices:

• Device Under Test (DUT)
• OpenEPT Device
• OpenEPT GUI

Figure 1 illustrates these three devices along with the connections between them.

The Device Under Test (DUT), shown in Figure 1, is the device whose energy consumption is being measured. The energy usage of the software running on the DUT is continuously monitored by the OpenEPT device. At any moment during execution, the DUT can request the OpenEPT device to sample its current voltage and current values. Upon receiving this request, the OpenEPT device records the voltage, current, and the exact timestamp when the request was made. The Energy Debugging feature allows each request to be assigned a unique name, facilitating the identification of the software component that generated it. Voltage, current, time, and name form a unique identifier for an energy event, referred to as an Energy Point. Once an Energy Point is created, its data is transmitted via the Ethernet interface to the OpenEPT GUI application for visualization. If for example, consumption of the specific function inside software wants to be measured, it is required to create two energy points – at the start and at the end of the function.

Energy Debugging Protocol

The OpenEPT Energy Debugging Protocol (EDP) consists of both a hardware interface and a communication protocol. The hardware interface, named Energy Debugging Interface (EDI) utilize standard serial connection (such as I2C or UART) and a GPIO pin. The communication protocol defines the messages exchanged between the OpenEPT device and the Device Under Test (DUT) to enable its energy consumption sampling.

Energy Debugging Interface - EDI

The hardware component of the Energy Debugging Protocol (EDP) is referred to as the Energy Debugging Interface (EDI). This interface enables precise energy consumption sampling of the Device Under Test (DUT) with accurate timestamps while simultaneously assigning a unique name to each sampled value. Typically, it combines standard serial interface, like I2C, SPI, or UART, along with an additional SYNC signal. The serial interface facilitates message exchange between the DUT and the OpenEPT device, while the SYNC signal ensures low-latency energy sampling requests. In the current version of OpenEPT software, UART is the only supported serial interface, and a GPIO pin on the STM32 platform is used as the SYNC signal. The interface and its relevant signals are illustrated in Figure 2.

Communication Protocol

Sync signal is used to send sampling request to OpenEPT device. Sampling request on OpenEPT device is trigger on both edges of Sync signal: rising and falling. When sampling request is triggered, current voltage and current values are recorded on OpenEPT Device.
Serial interface between DUT and OpenEPT is used to exchange messages between these two. These messages are in ASCII format and have following structure:

‍
<type>:<content>\r
‍

The type field identify message categories. Currently, three message categories are supported:

• Command (type = 0)
• Energy Point Name (type = 1)
• Info (type = 2)

The command message category is used to send specific instructions to the OpenEPT device. When a command message is sent from the DUT, a corresponding response from the OpenEPT device is expected, indicating the execution status. Currently, two key commands are supported: START and STOP. The START command is sent by the DUT once it has been successfully initialized, signalling to the OpenEPT device that it is ready to begin sending energy sampling requests. This command is crucial as it ensures that the OpenEPT device properly prepares its internal structures to receive energy requests. If the OpenEPT device successfully completes this preparation, it responds with an OK message; otherwise, it sends an ERROR response. Similarly, the STOP command is sent from the DUT to notify the OpenEPT device that no further energy sampling requests will be made, and its response follows the same format as the START message.
The Energy Point Name message category is associated with energy sampling requests. When the DUT issues a new energy sampling request by changing SYNC level (generating edges), it is expected to send a corresponding name along with it. The OpenEPT device then matches the energy sampling request, triggered by the Sync signal, with the appropriate name. This message category doesn’t expect response. The time diagram in Figure 3 illustrates the transmission of Energy Point Name messages corresponding to energy sampling requests.

Info message category is used to transmit arbitrary messages from the DUT. During energy profiling of DUT, these messages are often utilized to provide insights into software execution. In the current OpenEPT device firmware, these messages are forwarded to the OpenEPT logging interface. This message category preserves serial interface to be used for other purpose but also allows functional debugging of the DUT’s software.

Processing Energy Sampling Requests inside OpenEPT Device

Inside OpenEPT Device’s firmware is implemented energy debugging service which primary functionality is to receive and process energy sampling request by recording PacketID and SampleID when energy request is issued. Figure 4 illustrates software architecture of this service. To fully understand algorithms implemented inside this service, it is important to understand samples streaming and network functionalities first.

Complete code of this service is implemented within energy_debugging.c and energy_debugging.h file located on following path: Source/ADFirmware/CM7/Core/Middlewares/Services/ED/ wihin Firmware repository

‍

When a rising or falling edge of the Sync signal is detected, the corresponding Sync Interrupt Service Routine (ISR) is triggered. As the first step within this ISR, a request is made to the Analog Interface (AIN) software block to retrieve two values: PacketID and SampleID.  PacketID uniquely identifies a streaming packet, as ADC samples are transmitted in chunks of 500 samples. SampleID represents the specific sample within that chunk. The PacketID matches the ID of the packet that will be sent over the UDP interface, while the SampleID is obtained from the DMA counter. Once these values are retrieved, they are stored in the corresponding Value structure, which is then added to the Values queue.

The Serial ISR is responsible for receiving metadata messages. It gathers characters received over the serial interface, configured for use within the Energy Debugging Interface (currently implemented as UART in the OpenEPT firmware), and stores them in a corresponding buffer. When a \r (carriage return) character is detected, the buffer contents are transferred to a corresponding Name structure and then added to the Names queue.

The Energy Points Processing (EPP) module integrates the core functionalities of the Energy Debugging mechanism. This task reads from two queues, with only the Names queue being a blocking read. When the Serial ISR writes a Name structure instance to the Names queue, it unblocks the EPP task, which then analyses the received metadata messages to determine their type. Three possible processing scenarios are possible:

1. If the message is a START or STOP command, the system initializes communication by setting up all relevant buffers and generate response that will be sent back to the DUT
2. If the message is of type Energy Point Name, the task performs a non-blocking read from the Values queue. If the Values queue is empty, an error is generated; otherwise, the retrieved PacketID, SampleID, and Sample Name are combined to create a corresponding Energy Point. The generated Energy Point message is then written to the Energy Point (EP) queue.
3. If the message is logging message, received message content is forwarded to the OpenEPT logging interface

Energy Debugging Client (EDC) Task perform blocking read from EP queue to obtain EP messages after which it extracts content from EP messages and transform it to binary format message named EPBinary. This message will be sent over TCP to OpenEPT GUI application, and its format is illustrated on Figure 5.

This EPBinary message format consists of following fields:

• PacketID (4B wide) – represents packetID to which EP message is related to
• SampleID (4B wide) – id of sample inside the packet to which EP message is related to
• Name (nB wide end with \r\n characters) – name of the EP

Visualizing Energy Points inside OpenEPT GUI Application

The OpenEPT GUI application is responsible for receiving Energy Point samples, matching them with the corresponding current, voltage, and consumption values, and displaying them within the appropriate graphs. Additionally, it can store Energy Points for later offline processing. The classes within the OpenEPT GUI application that handle the reception, processing, and visualization of Energy Points, along with their interconnections, are illustrated in Figure 6.

The EDLink class encapsulates the functionality responsible for receiving EPBinary messages from the OpenEPT device and forwarding them for further processing, as illustrated in Figure 6. This class runs a TCP server that listens on a predefined port. Upon receiving an EPBinary message, it extracts the PacketID, StreamID, and Name, then generates the sigNewEPNameReceived signal. These extracted values, are passed as arguments with the signal.

Code of EDLink class is implemented within edlink.cpp and edlink.h files located on following path: Source/Links wihin GUI repository

The onNewEPNameReceived slot of the EPProcessing class receives the PacketID, StreamID, and Name from EDLink and processes them to compute the absolute energy sample position since the start of the stream acquisition.

When the absolute energy point position is calculated, this value, together with energy sample name, if forwarded to the Device class by sigEPProcessed signal.

Code of EPProcessing class is implemented within epprocessing.cpp and epprocessing.h files located on following path: Source/Processing wihin GUI repository

The Device class receives the absolute energy point position and checks the acquisition status. If the acquisition is stopped or paused, the energy point is rejected; otherwise, it is forwarded to the DeviceContainer class. Upon receiving the absolute energy point position, the DeviceContainer class utilizes it within its deviceWnd and fileProcessing members. The deviceWnd member visualizes the energy point position during acquisition based on the received value. Once the Energy Point (EP) is displayed, it is also forwarded to the fileProcessing member, which records the position in the ep.csv file, generated within the OpenEPT GUI workspace selected at program startup. OpenEPT GUI which ilustrates reception of Energy Points is illustrated on Figure 7.

In addition to the real-time visualization of Energy Points during DUT execution, the file-saving mechanism enables the DataAnalyzer feature in OpenEPT GUI to support offline plotting, enhancing post-analysis capabilities.

Profiling energy consumption of different MCU based platforms with OpenEPT

The OpenEPT Device enables energy consumption profiling for any MCU-based platform. The only requirement for this platform is to provide one UART interface and one GPIO pin. If this hardware requirement is met, Energy Debugging Communication Protocol should be implemented on MCU, and it will be possible to visualize its energy consumption with OpenEPT GUI.

Based on first section where Energy Debugging Protocol is described, it is noticeable that protocol is very simple to implement, and it introduce minimal latency to the system which consumption is measured. However, to reduce development time and enable easier utilization of OpenEPT toolset, within this project is also developed platform independent communication protocol library named Firmware Energy Profiling Library (FEPLib) which is available on this link. A detailed porting guide, along with example implementations for STM32 and ESP32 platforms, is provided here.