Profile (Energy Profiler)

General Description

The energy profiler driver is an API for configuring and using the profile hardware block.

The functions and other declarations used in this driver are in cy_profile.h. You can include cy_pdl.h to get access to all functions and declarations in the PDL.

The profile block enables measurement of the signal activity of select peripherals and monitor sources during a measurement window. Using these measurements, you can construct a profile of the energy consumed in the device by scaling the individual peripheral activities with appropriate scaling (weight) factors. This gives the application the ability to monitor the energy consumed by the internal resources with minimal CPU overhead and without external monitoring hardware.

Details

Profile Hardware

The profile hardware consists of a number of profile counters that accept specific triggers for incrementing the count value. This allows the events of the source (such as the number of SCB0 bus accesses or the duration of time the BLE RX radio is active) to be counted during the measurement window. The available monitor sources in the device can be found in the en_ep_mon_sel_t enum in the device configuration file (e.g. psoc62_config.h). These can be sourced to any of the profile counters as triggers. There are two methods of using the monitor sources in a profile counter.

• Event: The count value is incremented when a pulse event signal is seen by the counter. This type of monitoring is suitable when the monitoring source of interest needs to count the discrete events (such as the number of flash read accesses) happening in the measurement window.
• Duration: The count value is incremented at every clock edge while the monitor signal is high. This type of monitoring is suitable when a signal is active for a finite amount of time (such as the time the BLE TX radio is active) and the duration must be expressed as number of clock cycles in the measurement window.

Many of the available monitor sources are suitable for event type monitoring. Using a duration type on these signals may not give valuable information. Review the device TRM for more information on the monitor sources and detail on how they should be used.

Measurement Types

Depending on the item of interest, energy measurement can be performed by using the following methods.

• Continuous measurement: A profile counter can be assigned a monitor signal of constant 1 (PROFILE_ONE), which sets the counter to increment at every (assigned) clock cycle. This can be used to give a reference time for the measurement window and also allows the construction of timestamps. For example, a software controlled GPIO can be "timestamped" by reading the counter value (on the fly) before it is toggled. When the measurement window ends, the energy contribution caused by the GPIO toggle can be incorporated into the final calculation.
• Event measurement: Monitored events happening in a measurement window can be used to increment a profile counter. This gives the activity numbers, which can then be multiplied by the instantaneous power numbers associated with the source to give the average energy consumption (Energy = Power x time). For example, the energy consumed by an Operating System (OS) task can be estimated by monitoring the processor's active cycle count (E.g. CPUSS_MONITOR_CM4) and the flash read accesses (CPUSS_MONITOR_FLASH). Note that these activity numbers can also be timestamped using the continuous measurement method to differentiate between the different task switches. The activity numbers are then multiplied by the associated processor and flash access power numbers to give the average energy consumed by that task.
• Duration measurement: A peripheral event such as the SMIF select signal can be used by a profile counter to measure the time spent on XIP communication through the SPI interface. This activity number can then be multiplied by the power associated with that activity to give the average energy consumed by that block during the measurement window. This type of monitoring should be performed only for signals that are difficult to track in software. For example, a combination of interrupts and timestamps can be used to track the activity of many peripherals in a continuous monitoring model. However tracking the activity of signals such the BLE radio should be done using the duration measurement method.
• Low power measurement: The profile counters do not support measurement during chip Deep Sleep, Hibernate, and off states. I.e. the profile counters are meant for active run-time measurements only. To measure the time spent in low power modes (LPM), a real-time clock (RTC) should be used. Take a timestamp before LPM entry and a timestamp upon LPM exit in a continuous measurement model. Then multiply the difference by the appropriate LPM power numbers.

Driver Usage

At the highest level, the energy profiler must perform the following steps to obtain a measurement:

1. Initialize the profile hardware block.
2. Initialize the profile interrupt (profile_interrupt_IRQn).
3. Configure, initialize, and enable the profile counters.
4. Enable the profile interrupt and start the profiling/measurement window.
5. Perform run-time reads of the counters (if needed).
6. Disable the profile interrupt and stop the profiling/measurement window.
7. Read the counters and gather the results.
8. Calculate the energy consumption.

Refer to the SysInt driver on the details of configuring the profile hardware interrupt.

The profile interrupt triggers when a counter overflow event is detected on any of the enabled profile counters. A sample interrupt service routine Cy_Profile_ISR() is provided, which can be used to update the internal counter states stored in RAM. Refer to the Configuration Considerations for more information.

Configuration Considerations

Each counter is a 32-bit register that counts either a number of clock cycles, or a number of events. Overflowing the 32-bit register is possible. To address this issue, the driver implements a 32-bit overflow counter. Combined with the 32-bit register, this gives a 64-bit counter for each monitored source.

When an overflow occurs, the profile hardware generates an interrupt. The interrupt is configured using the SysInt driver, where the sample interrupt handler Cy_Profile_ISR() can be used as the ISR. The ISR increments the overflow counter for each profiling counter and clears the interrupt.

More Information

See the profiler chapter of the device technical reference manual (TRM).

MISRA-C Compliance

MISRA Rule	Rule Class (Required/Advisory)	Rule Description	Description of Deviation(s)
12.4	R	Right hand operand of '&&' or '||' is an expression with possible side effects.	Function-like macros are used to achieve more efficient code.
16.7	A	A pointer parameter can be of type 'pointer to const'.	The pointer is cast for comparison purposes and thus can't be a const.

Changelog

Version	Changes	Reason for Change
1.20.1	Minor documentation updates.	Documentation enhancement.
1.20	Updated API function Cy_Profile_GetSumWeightedCounts().	Minor defect fixing: now the function supports the correct number of counters.
1.10	Flattened the organization of the driver source code into the single source directory and the single include directory.	Driver library directory-structure simplification.
	Added register access layer. Use register access macros instead of direct register access using dereferenced pointers.	Makes register access device-independent, so that the PDL does not need to be recompiled for each supported part number.
	Added parameter check asserts.	Driver defect fix.
1.0	Initial version

API Reference
	Macros
	Functions
	Data Structures
	Enumerated Types