Understanding & Managing the Plethora of MCU Low-Power Modes
By Jason Tollefson,
Microchip Technology Inc., with Lynnette Reese, Mouser Electronics
Low Power MCU Design Series
Featured Products
Many MCUs have upwards of nine power modes to choose from these days. Further complicating things, each vendor gives its brand of mode a different name. This makes it very difficult to do a comparison and understand what the mode does. What do power modes do to the MCU? Here, we will break each mode down, list some industry names, and specify when to use each mode and why. Lastly, we will give an example of an application in which power modes are used and how the benefits affect battery life.
Let’s see how these technologies work, referring to Table 1. We start in full run mode, where our MCU is consuming full current. In PIC® Microcontrollers, there is a Doze Mode. Doze Mode runs the CPU and Flash Memory at a lower clock rate than the rest of the chip. This improves power consumption, as the Flash and CPU are very power hungry.
Idle Mode is next, with lower power consumption than Doze Mode. As the name suggests, in Idle Mode, the CPU and Flash are stopped. The rest of the chip continues to operate in this mode. If you do not need to execute code, but are taking a sensor measurement with the A/D or communicating to a radio, Idle Mode should be used.
After Idle is Sleep mode. In sleep mode, we save more than 90% of the power consumed in Run. The CPU, Flash, and most peripherals are disabled or offline in this mode. Some peripherals are available, like the A/D, UART Interrupt, and some timers, which allow the microcontroller to accomplish some work in the system, waking up the MCU at a specific time.
Typically, microcontrollers achieve the lowest power consumption in sleep mode, consuming mere nanoamps or microamps of current. Sleep has another option, too. A second regulator can be employed to reduce the voltage to the logic gates. This significantly reduces the leakage current of the MCU. The wake time will increase slightly, but most of the same functionality is available.
But that’s not as low as it goes. There is also a mode called Deep Sleep, where power is removed from most of the chip. The CPU, flash, RAM, and nearly all peripherals are disabled. They no longer have leakage current, because power is physically removed from them. Only a few specialized, low power peripherals remain powered. These peripherals are the Real-Time Clock, Deep Sleep Brown-out for detecting battery droop, a watchdog timer, and the ultra-low power wake up, a wake-up feature consuming only 150nA. With power removed from most of the chip, the current consumption can be as low as 20nA. Enabling peripherals in Deep Sleep increases the current slightly.
Table 1
| Run | ON | ON | ON | ON | ON | 0% | Full current consumption. |
| Doze | Slower Clock Rate | Slower Clock Rate | ON | ON | ON | 25-65% | CPU is slowed down to as much as 1/128 of its Run mode speed. |
| Idle | OFF | OFF | ON | ON | ON | 70% | Use in moments when code execution is not needed |
| Sleep | OFF | OFF | OFF - Except for peripherals with their own clock | ON | ON | 70% - 85% | RAM and registers maintained. Latencies of up to tens of microseconds are expected. |
| Low Voltage Sleep | OFF | OFF | OFF - Except for peripherals with their own clock | Low Voltage Enabled | ON | 90% | For longer-term sleep than Sleep, when longer latencies are acceptable. |
| Deep Sleep | OFF | OFF | OFF | OFF | OFF | 97%+ | Most of the MCU is OFF except for maybe a timer, interrupt handling, and a Real Time Clock and Calendar. |
Stop or Slow the Engine
This is the high level view of what happens. However, there are specific concerns and reasons for why one might use a particular mode. When you transition from Run to Idle or Doze modes, you are slowing the engine of the MCU. The CPU and Flash are suspended. This immediately gives you up to 70% current savings. Vendors call this mode Idle, Doze, Sleep, or Wait in reference to the state of the CPU, which is slowed down to as much as 1/128 of its Run mode speed. The state of the RAM and registers are maintained. Still, most MCUs allow for the peripherals to run at full speed in this mode. This provides some real benefits. For example, if the user is running a communication protocol and has just loaded the UART with data, he can enter Idle mode and wait for the transmission to end. The CPU will restart once the UART interrupt is received. There is no loss of BAUD rate with this kind of action, and no down time is experienced. However, with a slower core, there is increased latency, or slower response time.
Stop the Clock
On a PIC MCU, running at 2MHz can consume about 300µA, but in Idle that number is nearer to 80µA. When going from Run to Sleep mode, the savings are even greater at up to 97%. This mode is called many names in the industry: Sleep, Stop, LV Sleep, VLP Stop, and so forth. The bottom line is that, in this mode, the CPU, flash, and system clock have been stopped. This means any peripheral without its own clock source cannot run in this Sleep mode.
Vendors have created peripherals with self-contained clocks to take care of this requirement. Common peripherals that are enabled to run in Sleep mode are LCD displays, some analog devices, timers, and anything that can send interrupts. For example, UARTs can see an interrupt and wake the MCU. In this Sleep mode, RAM and the registers are maintained. This mode is used when no processing is required and the system can tolerate a delay of tens of microseconds in code execution. This happens when awaiting a button push, a timer to expire, or an ADC measurement to finish. Sleep mode uses just 1/500th of the current consumed in Run mode.
Pull the Power Plug
Many vendors now include a new set of modes called “sub-sleep”. They can be called Deep Sleep, Standby, VLLx Stop and more. These modes turn off power to portions of the MCU, leaving a small island of logic alive. In these islands you will typically find a timer, interrupt handling, and Real Time Clock and Calendar (RTCC). The core, peripherals, and memory are stopped. Memory is lost, with a long recovery that requires a full initialization, taking from hundreds of microseconds to one millisecond.
Designers will lose all RAM and register content, as the power was removed. However, you get 5,000 times less the power consumption, down to the low nanoamps. The PIC can consume as little as 0.04 µA in this mode. Designers might choose this mode when their application will be stored, perhaps prior to sale or first use. Another time could be when the application is inactive for a long time, as in tens of minutes, or perhaps sensing data twice an hour. There is a long recovery from this mode, since the MCU must boot from code as is experienced with a reset. But of course, this wait is offset by massive current savings.
Other Influences on Current Consumption
The above describes power modes on MCUs, but there is still more to be done to save current. Software and firmware affect current, too. Inefficient code can burn more cycles. One example is the While loop. If you implement a While loop on the PIC24F running at 1MHz, the current consumed is about 230uA. However, if you replace that While loop with a Repeat instruction followed by NOP (No Operation), just 95µA is consumed and you achieve the same goal. Therefore, indifferent coding can drive power consumption to double each time you execute a routine in your program, and much more if the routine is executed often.
Finally, users should study the peripherals of an MCU closely. Many have built-in power reduction features. For example, some ADCs have sample timers that are associated with a threshold value. Sample timers allow the ADC to periodically sample and compare to a threshold in Sleep mode. Or the ADC can wake the MCU when a condition is met. This can save as much as 87% power.
Measure Results
To measure the effects of coding, peripherals, and power modes on current consumption, it helps to have a platform that can test these effects while coding. Many vendors make this process faster by offering current measurement probes that can be integrated into their integrated development environment (IDE.)
Conclusion
To conclude, we will look at one more example: a wireless sensor. In this case, a battery-powered environmental sensor tracks temperature, time, and ambient light. This sensor is powered by two AA batteries and features a 2.4GHz radio. We’ll use a handy tool called the “Battery Life Estimator” to map out our program flow with respect to power consumption. The battery life estimator models the operation of the MCU, battery, and surrounding circuitry to provide an estimate of battery life and peak current demand. The data we enter into the estimator is set up just like our program is coded; with sensor acquisition, data processing, radio communication, radio transmission, and sleep.
In the first pass, we do not utilize the Idle or Doze modes and only enter Sleep when done acquiring and transmitting the data. Our battery life is estimated to be 47 days with an average current of 2.5mA.By using the Idle and Doze modes and factoring in these changes to our estimator, we find a dramatic improvement. The application now lasts 1 year and consumes an average current of only 300µA, a 10X reduction in power consumption.
Power modes can increase battery life by 87%, as in 47 days versus 365 days. Each power mode has specific use cases that are dependent on hardware, software, peripherals, and response time requirements. Navigating through modes is easier once you know their names and uses.
Jason Tollefson is Sr. Product Marketing Manager for Microchip Technology, specializing in low-power MCUs and the PIC24 and dsPIC microcontroller product lines.
Jason holds a Bachelor’s degree in Electrical Engineering from the University of Minnesota’s Institute of Technology, and a M.B.A from the University of Phoenix. Jason worked in new-product development, including design/test/product engineering, for 8 years prior to changing careers to marketing.
Lynnette Reese is a member of technical staff at Mouser and holds a B.S. in Electrical Engineering from Louisiana State University. Prior to her position at Mouser, she completed a combined 15 years in technical marketing in embedded hardware and software with Texas Instruments, Freescale, and Cypress Semiconductor. She enjoys gadgets of all types and is an aspiring geek goddess.
