“Power debug techniques enable software engineers to understand the impact of embedded system software on system power consumption. By establishing the link between source code and power consumption, it is possible to test and adjust system power consumption, which is called power consumption debugging. Traditionally, reducing power consumption has only been a design goal of hardware engineers; however, in actual operating systems, power consumption depends not only on the design of the hardware, but also on how the hardware is used, which is controlled by the system software .
Power debug techniques enable software engineers to understand the impact of embedded system software on system power consumption. By establishing the link between source code and power consumption, it is possible to test and adjust system power consumption, which is called power consumption debugging. Traditionally, reducing power consumption has only been a design goal of hardware engineers; however, in actual operating systems, power consumption depends not only on the design of the hardware, but also on how the hardware is used, which is controlled by the system software .
Figure 1: IAR Systems’ C-SPY debugger can Display static and dynamic power consumption data in different views.
Power debug techniques are based on sampling power consumption and correlating each sampled data with the program’s instruction sequence (and source code). One of the difficulties lies in achieving high-precision sampling. Ideally, power consumption should be sampled at the same frequency as the system clock, but capacitive components in the system reduce the reliability of such measurements. From a software engineer’s point of view, the link between power consumption and source code and various events during program execution is more of interest than individual instructions, so the required sampling resolution will be significantly lower than for each The frequency at which an instruction is sampled.
The measurement of power consumption is done by the debug tool. For example, the debugging tool supported by IAR Embedded Workbench is IAR J-Link Ultra. It can measure the voltage drop of the chip’s power supply after passing a small resistor in series, as shown in Figure 2. This voltage drop is measured using a differential amplifier and sampled by an analog-to-digital converter.
Figure 2: The IAR J-Link Ultra measures the voltage drop across the chip’s power supply through a small series resistor.
To improve the accuracy of power debugging, the key is to establish a good correlation between instruction trace and power sampling. Optimal affinity is only possible when full instruction tracing is possible, but it has the disadvantage that not all chips support this feature; even if it does, special debugging tools are usually required.
To achieve better correlation at lower accuracy, the PC sampling feature supported by some modern on-chip debug architectures can be used. This function samples the PC periodically and gives a timestamp for each sample. At the same time, the debug tool uses an analog-to-digital converter to sample the power consumption of the chip. By comparing the time stamps of the power sampling values and the PC sampling values, the debugger can display power consumption data and graphics such as interrupt records and variable monitoring on the same timeline, and associate the power consumption data with the source code. See image 3.
Figure 3: PC and Power Sampling Correction.
In general, power optimization is very similar to speed optimization. The faster a task runs, the longer the low-power mode can last. Therefore, maximizing the idle time of the processor can reduce the power consumption of the system.
It can be difficult to identify unnecessary energy consumption in a system and where to reduce it. Often they’re not obvious flaws in the source code, but more of a tweak to the way the hardware is used.
Waiting for the status of the device
A common mistake that causes unnecessary power consumption is using polling to wait for a change in the state of a peripheral. In the example below, the code runs uninterrupted until the state variable changes to the expected value.
MC_SR & MC_MCKRDY)! = PMC_MCKRDY);
Another similar code is to implement a software delay in a for or while loop, for example:
i = 10000; // SW Delay
while (i != 0);
This code keeps the CPU busy executing instructions that have no effect other than timing.
In these cases, the power consumption can be reduced by rewriting the code. The delay is best implemented by hardware timers. After setting the timer interrupt, the CPU can enter the low-power mode until it is woken up by the interrupt. Likewise, polling of peripheral status should be handled by interrupts if possible, or by using timer interrupts so that the CPU can go to sleep between polls.
Traditionally, DMA has been used to increase transfer speed. In some architectures, the CPU can enter sleep mode even during a DMA transfer. Power debug enables developers to experiment and see through the debugger how DMA technology works compared to traditional CPU-driven transfers.
low power mode
Many embedded applications spend most of their time waiting for some event to occur. If the processor is still running at full speed when idle, the life of the battery will be drained by doing very little. So in many applications, the processor is only activated for a small amount of time in total. By placing the processor in a low-power mode during idle time, battery life can be extended by orders of magnitude.
A good way is to use RTOS and task oriented design. It is possible to define a lowest priority task that will only be run when there are no other tasks to run. This idle task would be an ideal place to implement power management. In practice, each time an idle task is activated, the processor (or part thereof) is put into one of (possibly) many low-power modes.
CPU frequency Theoretically, the power consumption of CMOS MCU can be obtained by the following formula: P = fx U^2 xk In the above formula, f is the clock frequency, U is the supply voltage, and k is a number. Power debug enables developers to verify the relationship between power consumption and clock frequency. A system running at 50MHz and barely sleeping will consume about 50% of the time in sleep mode when running at 100MHz. The power consumption data in the debugger enables the developer to verify the desired behavior and, if there is a non-linear relationship with clock frequency, to choose the operating frequency with the lowest power consumption.
Figure 4 shows a schematic diagram of the power consumption of an event-driven system, which is in inactive mode at t0 and consumes a current of I0. At t1 the system is activated and the current rises to I1, corresponding to the power consumption when the system is in active mode and one peripheral is used. At t2, program execution is suspended by a higher priority interrupt. Peripherals that have been activated are not turned off, although they are not used by high-priority threads. More peripherals are activated by the new thread, causing the current to rise to I2 between t2 and t3. At t3, the control weight goes back to the low-priority thread.
Figure 4: A schematic diagram showing the power consumption of an event-driven system.
The system can be very functional and can be optimized for both speed and code size. In terms of power consumption, however, there are more optimizations that can be achieved. The yellow area in the figure represents the energy that can be saved if unnecessary peripherals are turned off between t2 and t3, or the priorities of the two threads are reversed.
Using power debug, it is easier to spot the extra rise in power consumption when an interrupt occurs and flag it as an anomaly.
Find conflicting hardware initializations
To avoid floating inputs, unused MCU I/O pins are grounded in common designs. If software mistakenly configures a ground pin to output a logic “1”, up to 25mA can flow to that pin. This undesired high current is easily observable on the power sampling graph; the associated initialization error code can also be found by observing the graph during system startup.
Analog glitches can also have an impact on power debug. Analog-to-digital hybrid circuit boards have their own characteristics. Board-level layout and traces are important for suppressing analog noise and ensuring accurate sampling of low-level analog signals. Good mixed-signal circuits require careful consideration and careful design of the hardware.
Power debug enables embedded system developers to gain insight into their applications and discover how a program’s code affects power consumption. Based on this information, the source code can be tuned and optimized to minimize power consumption. Using this approach, engineers can ensure that their designs have saved as much energy as possible without adversely affecting system performance.