“Why is my processor power consumption greater than the data sheet value? I remember one time a client walked into my office with a processor board and said it was drawing too much power and draining the battery. Since we proudly claimed that this processor is an ultra-low power device, the burden of proof is on our side. I was going to cut power to the different components on the board one by one as usual until I found the real culprit, when I remembered a similar case not long ago, where the “culprit” was a man hanging alone between the power rail and the ground. There is no current-limiting resistor to be associated with the LED in between.
Why is my processor power consumption greater than the data sheet value?
I remember one time a client walked into my office with a processor board and said it was drawing too much power and draining the battery. Since we proudly claimed that this processor is an ultra-low power device, the burden of proof is on our side.
I was going to cut power to the different components on the board one by one as usual until I found the real culprit, when I remembered a similar case not long ago, where the “culprit” was a man hanging alone between the power rail and the ground. There is no current-limiting resistor to be associated with the LED in between. Whether the LED eventually failed due to overcurrent, or simply because it was boring, I’m not entirely sure, but that’s off topic and we’ll leave that aside.
From experience, the first thing I do is check the circuit for sparkling LEDs. But unfortunately, there is no similar glimmer of hope this time around. Also, I found that the processor was the only device on the board, and there was no other device I could blame. The next piece of information from the customer made my mood even lower: Through lab tests, he found that power consumption and battery life were at expected levels, but after deploying the system in the field, the battery was draining rapidly. Such problems are the most difficult to solve because they are very difficult to reproduce the “first crime scene”. This adds analog unpredictability and challenges to the problem of the digital world, which is often just a predictable, simple world of 1s and 0s.
In the simplest sense, there are two main aspects of processor power consumption: cores and I/O. When it comes to curbing core power consumption, I check things like: PLL configuration/clock speed, core supply rails, core operations. There are various ways to reduce core power consumption, such as reducing the core clock speed, or executing certain instructions to force the core to stop running or go to sleep/hibernate. If I suspect that the I/O is eating all the power consumption, I would look at the I/O power supply, the I/O switching frequency and the load it drives.
These are the only two aspects I can explore. It turns out that the problem has nothing to do with the kernel, so it must be related to I/O. At this point, the customer stated that he was using the processor purely for computation, with minimal I/O activity. In fact, most of the available I/O interfaces on the device are not used.
“Wait! Some I/Os you don’t use? You mean these I/O pins are unused. How did you connect them?”
“I didn’t connect them anywhere!”
It was an ecstatic moment when I finally found the problem. While not screaming along the way, it did take me a while to hold back my excitement and sit down to explain it to him.
A typical CMOS digital input looks like the following figure:
Figure 1. Typical CMOS input circuit (left) and CMOS level logic (right)
When driving this input at the recommended high (1) or low (0) level, the PMOS and NMOS FETs are turned on one at a time, never at the same time. The input drive voltage has a region of uncertainty, called the “threshold region,” where the PMOS and NMOS may be partially turned on at the same time, creating a leakage path between the supply rail and ground. This can happen when the input is floating and encounters spurious noise. This explains both the fact that the power consumption is high on the customer’s board and why the high power consumption occurs randomly.
Figure 2. Both PMOS and NMOS are partially on, creating a leakage path between power and ground
In some cases, this can lead to conditions like latch-up, where the device continues to draw excessive current and eventually burns out. It can be said that this problem is easier to find and solve, because the device in front of you is smoking, and the evidence is solid. The problem reported by my clients is more difficult to deal with because when you test it in the cool environment of the lab it’s fine, but when it’s sent to the field it can cause a lot of trouble.
Now that we know the source of the problem, the obvious solution is to drive all unused inputs to a valid logic level (high or low). However, there are some subtleties to be aware of. Let’s look at a few more troublesome situations where mishandling of CMOS inputs can cause problems. We need to expand the scope to consider not only inputs that are completely disconnected/floating, but also inputs that appear to be connected to appropriate logic levels.
If the pin is only connected to a supply rail or ground through a resistor, be careful with the size of the pull-up or pull-down resistor used. It, along with the pin’s source/sink current, can shift the pin’s actual voltage to an undesired level. In other words, you need to make sure that the pull-up or pull-down resistors are strong enough.
If you choose to drive the pins actively, it is important to ensure that the drive strength is good enough for the CMOS load used. If this is not the case, the noise around the circuit may be strong enough to exceed the drive signal, forcing the pin into an unintended state.
Next, let’s examine a few scenarios:
A processor that works properly in the lab may reboot inexplicably in the field because noise is coupled into the RESET line that doesn’t have a strong enough pull-up resistor.
Figure 3. Noise coupling into the RESET pin with a weak pull-up resistor can cause a processor restart
Imagine a situation where the CMOS input belongs to a gate driver that controls a high power MOSFET/IGBT that turns on unexpectedly when it should turn off! Simply terrible.
Figure 4. Noise overdrives a weakly driven CMOS input gate driver, shorting the high-voltage bus
Figure 6. ADSP-SC58x/ADSP-2158x Data Sheet Quick Reference
Another related but less obvious problem situation is when the rise/fall of the drive signal is very slow. In this case, the input may stay at midscale for a certain amount of time, causing various problems.
Figure 5. Slow rise/fall of CMOS input, causing temporary short during transition
We’ve discussed some of the problems that can occur with CMOS inputs in a general sense, and it’s worth noting that some devices are better at handling these problems than others in terms of design. For example, devices with Schmitt trigger inputs are better able to handle signals with high noise or slow edges.
Some of our latest processors are also aware of this issue and have taken special precautions in their designs or issued clear guidelines to ensure smooth operation. For example, the ADSP-SC58x/ADSP-2158x data sheets clearly state that some pins have internal termination resistors or other logic to ensure that these pins do not float.
Finally, as is often said, it’s important to get all the finishing touches right, especially the CMOS digital inputs.