Reducing MCU power consumption without compromising response times -

Reducing MCU power consumption without compromising response times


Editor's Note: The ability to operate an MCU's peripherals independently from the core provides a powerful capability for embedded systems engineers. Developers can keep the MCU core in a low-power state while relying on MCU peripherals to respond to external events without involving the core. To help engineers use these techniques, Lucio Di Jasio provides background on MCU features and core independent peripherals, offering examples illustrating their use in his book,  This is (not) Rocket Science. In this excerpt from the book, the author describes the use of low-power modes and their use with core independent peripherals. 

Adapted from This is (not) Rocket Science, by Lucio Di Jasio, available from online booksellers including Amazon, Barnes & Noble, and Lulu.

Chapter 9. XLP – eXtreme Low Power

As 8-bit PIC® microcontrollers have become ever more capable, their power consumption has been squeezed to extreme levels. While not all applications need to operate from a battery for a decade straight as some marketing types would like you to believe, there are many advantages that can come from a more conservative use of energy. Smaller power supply circuits, less noise, less heat and hence smaller packages, and in general a small application form factor are all desirable features.

About a decade ago all PIC microcontroller designers committed to a common set of power consumption target figures called the eXtreme Low Power (XLP) standard. The original set included an ambitious maximum current consumption of the device when in Sleep (lowest-power mode) of 100 nA (that is nano Amperes!) But also the Watchdog and the Secondary Oscillator (SOSC) had a target of just 800nA each.

Today, all PIC16F1 devices routinely pass those criteria and by a wide margin.

In fact it is common to find on the device datasheet values that are almost an order of magnitude lower: 20nA in Sleep and less than 300nA for WDT and SOSC. Even the dynamic power consumption of the microcontroller, that is the current consumption when actually executing the application, has been similarly reduced by orders of magnitude with current values commonly in the 30 uA/MHz (micro Ampere per MHz of system clock).

These are values that would be very hard (if not impossible) to achieve with larger (16 and 32-bit) architectures because they require the use of much smaller, and therefore leaky, CMOS processes. In fact it is common for those architectures to adopt radical expedients (deep sleep modes) just to get near much less ambitious figures (few micro Amperes) at the cost of RAM contents loss and lengthy wake up times. None of that is necessary with the PIC16F1 microcontrollers as even when in the lowest-power mode they do preserve the full contents of the RAM memory and yet can wake up in microseconds.

Low Power Modes


Sleep has been the signature low power mode of all PIC microcontrollers from the beginning of time. Initially it was used to indicate a mode where the main system clock is stopped and with it pretty much any activity of the microcontroller save for the Watchdog timer thanks to its independent oscillator.

In the PIC16F1 generation of devices though, the list of independent oscillators available on chip has grown considerably and with it the number of possibilities. Sleep still means stopping the system clock, and therefore the core instruction execution, but many peripherals are capable of continuing their operation if configured to use the alternate oscillators. Examples of such peripherals include:

  • Timer1, a 16-bit timer, when using the Secondary Oscillator (SOSC) or when used as a counter in asynchronous mode.

  • Analog-to-Digital Converter (ADC), when using the dedicated internal oscillator (FRC)

  • All core independent peripherals when using directly one of the oscillators (for example HFIntOsc instead of Fosc/4).

Low Power Sleep

The low-power sleep feature must not be confused with the deep sleep mode of other architectures. It applies only to PIC16F1 devices that operate at 5V and therefore using the internal LDO. Such LDO can be switched to a lower power mode (with resulting lower quiescent current) when selecting the low power feature. Note that RAM contents integrity is fully preserved, but wake up time is affected as the return to full power requires a short stabilization delay.


There are several events that can force the microcontroller to exit the low power state and resume operation, including:

  • External Reset (MCLR)

  • BOR reset

  • Watchdog timer

  • Any external interrupt

  • Any interrupt produced by a peripheral that is operating asynchronously with the system clock

Regardless of the trigger event, waking up from sleep, the MCU will continue executing the instruction immediately following in program memory.

This is true even for peripherals that would otherwise generate an interrupt if the interrupt enable bit is cleared (not enabled).


Idle mode was introduced first in PIC18 models and more recently in PIC16F1 models (such as the PIC16F183xx and PIC16F188xx families) to allow the microcontroller to stop executing while keeping all other clock systems up and running, including those peripherals that are configured to operate off the system clock. The power savings achievable is noticeable but not remotely comparable to the savings achieved by Sleep mode.


Doze mode was similarly introduced in the most recent PIC16F1 families to further increase the granularity of power consumption control. When in Doze mode the core is allowed to continue to run although its clock source is divided further by a factor that can be selected between 1:2 to 1:256.

The result is once more a power consumption reduction proportional to the scaling factor chosen, with the benefit of allowing all peripherals to continue operating as well as some (reduced) core activity.

Doze Interrupt Boost

When in Doze mode, it is possible to configure the device so that an incoming interrupt will make the core return instantaneously to full speed. It is possible then to ensure that the core will return to doze mode upon interrupt exit. Effectively the combination of the two options can be used to produce a sort of interrupt boost. In other words, it is possible to conceive low power application where the main application loop is normally executed at a desired fraction of the clock (i.e. 1:8 = 4MHz) and only interrupt routines get to use the full speed and maximum performance the microcontroller is capable of (1:1 = 32MHz).

PMD – Peripheral Module Disable

The power consumption of a peripheral module that is not used by an application is typically very limited, but can be completely eliminated by disabling entirely the peripheral via the PMD control register available on the very latest generation of PIC16F1 devices (PIC16F183xx and PIC16F188xx for example).

A peripheral that is disabled does not receive anymore any of its clock and input stimuli. Its registers are not available anymore to the microcontroller core and all I/Os eventually assigned to it are released and returned to the next peripheral/option according to a pin priority.

When re-enabled, the peripheral state will be returned to the POR reset condition as documented in the device datasheet.

Achieving XLP

Achieving eXtreme Low Power consumption in an application requires much more than simply entering Sleep mode. Here is a short list of items that the designer should check, and consider turning off before entering Sleep mode, as they can impact significantly the resulting power consumption of the device:

  • I/O pins left floating

  • External circuits sinking current from I/O pins

  • Weak pull-up option if enabled

  • Modules using LFintOSC (i.e. Fail Safe Clock Monitor)

  • Core Independent peripherals that are left connected directly to oscillators (i.e. CWG or NCO and HFIntOSC)

  • Analog modules that make use of the internal voltage reference (FVR) when configured to use it (i.e. DACs, BOR, OPA, Comparators…)


MPLAB® Code Configurator (MCC) makes it easy to generate multiple initialization functions for each module. For example, beside the default initialization that will be used during the SYSTEM_Initialize() sequence, we can create a low power configuration to be used before entering Sleep mode.


Create a new initialization function for the FVR module, call it “Sleep” and set it so to turn off the entire module:

// < MCC generated code >

void FVR_Sleep(void)


    // CDAFVR off; TSRNG Lo_range; TSEN disabled;

    // FVREN disabled; FVRRDY disabled; ADFVR off;

    FVRCON = 0x00;


// < MCC generated code >

Have one of these for each module that could unnecessarily keep your application power consumption up and call them before going to sleep.

// turn all things off (but the chosen wake up)



// …

// go to lowest power mode





  • True low power design requires a well thought out plan. To get a clear picture of all the inter-dependencies between modules and to find the best possible configuration for your application, always check the “Operation in Sleep” section of each peripheral in the device datasheet.

  • Compare the wakeup capabilities of the Interrupt on Change feature vs. the CLC interrupt when used to detect external (digital) events.

  • Always refer to the datasheet for maximum values of power consumption in the application temperature and voltage range.

  • Read the excellent Low Power Report from Jack Ganssle (see link below) which dispels the many myths about ultra low power applications and provides excellent guidelines for reliable (and realistic) performance/long battery life.

Online Resources

Low-Power Design Guide App Note (AN1416)

Optimizing Battery Life in DC Boost Converters Using MCP1640 App Note (AN1337)

Selecting the Right Battery System for Cost-Sensitive Portable Applications While Maintaining Excellent Quality App Note (AN1088)

Design Practices for Low-Power External Oscillators App Note (AN1288)

Copyright © 2015 by Lucio Di Jasio. Reprinted by permission.

Lucio Di Jasio is the EMEA Business Development Manager for Microchip Technology Inc. He has been covering various technical and marketing roles within the company 8, 16 and 32-bit divisions for the past 18 years. As an opinionated and prolific technical author, Lucio has published numerous articles and several books on programming for embedded control applications. Following his passion for flying he has achieved both FAA and EASA private pilot license certifications. You can read more about Lucio's latest books and projects on his blog.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.