BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


EDITOR'S REPORT

Optimizing Power with Power Debugging

Power Debugging—Minimizing Power Consumption by Tuning the Code

Hardware power management features have long been used to extend battery life. Now, tools are becoming available that can get to finer levels of software design to optimize power usage in mobile devices.

TOM WILLIAMS, EDITOR-IN-CHIEF

  • Page 1 of 1
    Bookmark and Share

Article Media

For a vast number of embedded, handheld and mobile devices—most of which are battery operated—minimizing power consumption is a goal of ever-increasing importance. Low-power CPUs now have multiple levels of sleep modes and the capability of adjusting their clock frequencies to save power. Traditionally, the task of optimizing power consumption has fallen to the hardware engineers with the software developers making rather straightforward selections of different sleep modes under specific conditions.

But in today’s systems, the way the software runs in various situations can have a very significant effect on power consumption. For example, it makes a big difference if a processor goes into a loop to poll a port for an input or if the program sets a timer or waits for an interrupt to wake it from a low-power mode. Making such decisions is not always straightforward because it is not always clear which parts of the code may be unnecessarily consuming power even though they are functioning correctly.

To help developers explore the relationship between power consumption and code execution, IAR Systems recently introduced an in-circuit debugging probe that integrates seamlessly with the company’s IAR Embedded Workbench IDE. Called the I-jet, the probe connects to the target systems and enables the debugger to record power consumption at the same time it is doing the instruction trace that is needed for normal software debugging.

The probe supplies up to 5V at up to 400 mA to power the target and measures the voltage across an internal resistor to determine the power consumption as the code executes. Power is supplied via the USB connection to the host (Figure 1). The probe supports ARM7, ARM9, ARM11 and ARM Cortex-M/R/A cores. It does normal instruction trace using the processor’s instrumental trace module (ITM), which also supplies a time stamp to correlate power usage with instruction execution. While it would be ideal to sample the power consumption at the same clock frequency as the instructions are traced, system capacitances make doing this difficult. Therefore, the power samples are somewhat “smeared” across the instruction trace, but are certainly accurate enough to correlate closely with the source code, which is what the developer wants to concentrate on. Thus there will not be an exactly equal number of power samples to instruction samples.

Figure 1
I-jet power measurement. The probe uses the JTAG connector but traces instructions using Serial Wire Debug (SWD).

What the developer does get is a very good look at the power consumption correlated with code execution. The tool presents three views: the power log, the timeline and the function profiler. The power log (Figure 2) is a log of all collected power samples and can give the user a quick overview of where power peaks are occurring to enable him or her to quickly zero in on areas of interest. In addition, power logs can be saved as text or Excel files and used to compare different runs for changes in consumption at various points in the code.

Figure 2
The power log window displays time-stamped power readings in microA with the ability to click on these values and go to the other displays.

The timeline window (Figure 3) can be accessed by double clicking on either of the other windows. The timeline window displays interrupt activity and up to four application variables correlated with a display of the sampled power consumption. The display in Figure 3 shows one variable, g_state, with its different values along the x time axis.

Figure 3
The timeline window allows the user to follow the changes in power consumption associated with a function’s selected variables. From here one can click to view source code.

The power samples in the lower part of the figure represent the power consumption associated with the corresponding value of the variable. In this case, the power samples appear continuous, but in other cases they can appear as distinct vertical bars due to the differences in sampling times mentioned above. In either case they give a good idea of the correlation of code with power.

This particular example is from a demo that turns LEDs on and off depending on the value of g_state. Other cases will not necessarily be an exact correspondence with the numerical value. From the timeline window, it is just a double-click to the source code window. Here the user can review the source code to understand exactly what is going on. At the user’s option, he or she can try a different implementation of that particular function, recompile, rerun and compare the results in any of the three windows.

The third display is the function profile window, which also gives the developer a quick insight into those functions that may most need attention (Figure 4). Here, power consumption is displayed by function call. In the display it shows in the first column the number of times a given function ran and then the percentage of the total execution. In the third column are the number of times samples of the power consumption for a given function were taken. Notice that this number is less than the number of the actual count of the function executing. The fourth column displays the percentage of total power consumed in the run by each individual function. The last three columns show the average, minimum and maximum power draw for that function in microamps.

Figure 4
The power profile window shows the number of samples and the relative power consumption and execution figures for selected functions. From here one can click to view source code.

Once again, clicking on any function in the profile display will take the user to the corresponding source code. The profile display can be quite useful in that it also lets the user home in on those elements in the code that consume the most power. For example, it will make more sense to spend time investigating LCD_GetFlagStatus than it will LCD_WaitForSynchro due to its significantly higher rate of execution and the associated consumption of power even though the latter function has a slightly higher average power draw.

There are a number of things that can appear to operate quite correctly from a functional point of view but still be power hogs. For example, setting up a time delay or polling some port by means of a loop that executes until the status of the port changes can pull unnecessary power when it might be more efficient to set up an interrupt or set a hardware timer to implement a specific delay during which the processor could be put into a sleep mode and brought back up after the elapsed time. In the case of polling a port, setting up an interrupt that would bring the system back might be a better way of saving power. This, of course, must be weighed against the need to respond immediately or within some time window. In addition, setting the processor to a slower and then a faster clock speed can also be valuable under the proper circumstances.

The advantage to using the I-jet probe is that these things can be experimented with, the code recompiled and rerun to check the results. Immediate indication of results can be found by looking at the power log for changes to areas of interest, or for more complex searches, logs saved as Excel files can be automatically compared. From there one can click to the source code and immediately see what has happened and if necessary make further adjustments.

The sequence in which the developer uses these power debugging features is mostly a matter of individual choice. One might wish to make sure all the code is bug-free before attacking power optimization. On the other hand, some particular peak noticed during a first run could call attention to both a bug and an inefficient segment of code. For one thing, the developer will have to consider whether the additional instructions needed to implement some power-saving scheme will be worth the actual power saved. 

IAR Systems
Uppsala, Sweden
+46 18 16 78 00
www.iar.com