Why is my processor leaking?

I remember once that the customer walked into my office with the processor board and said that it consumed too much power and drained the battery. Since we have proudly claimed that the processor is an ultra-low-power device, the burden of proof lies on our side. I am prepared to follow the usual practice to cut off the power of different devices on the circuit board one by one until I find the real one. Then I remember a similar case not so long ago. The “culprit” of that case was a single hung on the power rail and ground. Between the LED, no current limiting resistor is associated with it. The ultimate failure of the LED is due to over-current, or simply because it is boring, I can not be completely sure, but this is a digression, we will not talk about. From an experience point of view, the first thing I did was to check the shiny LED on the circuit board. But unfortunately, this time there is no similar hope that shows the hope. In addition, I found that the processor is the only device on the board, and no other device can make me blame. The customer's next message sent me to a depressing mood: Through lab tests, he found that power consumption and battery life were at an expected level, but after the system was deployed to the scene, the battery was quickly depleted. Such problems are the most difficult problems to solve, because these problems are very difficult to reproduce the "first case of discovery." This adds analogic unpredictability and challenges to the problems of the digital world, and the digital world is usually just a predictable, simple 1 and 0 world.
In the simplest sense, there are two main aspects of processor power consumption: the core and I/O. When it comes to suppressing core power consumption, I check things like: PLL configuration/clock speed, core supply rails, kernel computations. There are several ways to reduce the power consumption of the core, for example: reduce the clock speed of the core, or execute some instructions to force the core to stop running or enter sleep/hibernation. If you suspect that I/O has consumed all power, I will focus on the I/O supply, the I/O switching frequency, and the load it drives.
There are only two aspects that I can explore. As a result, the problem has nothing to do with the kernel, so it must be related to I/O. At this time, the customer stated that he used the processor purely for calculations and had very little I/O activity. In fact, most of the available I/O interfaces on the device are not used.
"Wait! Some I/Os you didn't use. You mean these I/O pins are not used. How do you connect them?"
"Of course, I didn't connect them anywhere!"
"This is it!"
This is an ecstatic moment and I finally found the problem. Although I didn't scream along the way, it took me a while to hold my excitement and then sit down and explain to him.

The typical CMOS digital input is similar to the following figure:

Figure 1. Typical CMOS Input Circuit (Left) and CMOS Level Logic (Right)

When the input is driven at the recommended high (1) or low (0) level, the PMOS and NMOS FETs are turned on one at a time and never at the same time. The input drive voltage has an uncertainty region 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 spurious noise is encountered. This explains both the fact that the power consumption on the customer board is high and why high power consumption occurs randomly.

Figure 2. PMOS and NMOS partially turned on, creating a leakage path between the power supply and ground

In some cases, this may cause latch-up conditions, ie the device continues to draw excessive current and eventually burns. It can be said that this problem is easier to find and solve because the device in front is smoking and the evidence is conclusive. The problems that my clients report are even more difficult to deal with, because when you test in the cool environment of the lab, it has no problem, but when you send it to the scene, it will cause great trouble.
Now that we know the source of the problem, the obvious solution is to drive all unused inputs to valid logic levels (high or low). However, there are some minor things to note. Let's look at a few cases where the CMOS input is not handled properly. We need to expand the scope not only to consider completely disconnected/floating inputs, but also to consider inputs that appear to be connected to appropriate logic levels.
If you only connect the pin to the supply rail or ground through a resistor, pay attention to the size of the pull-up or pull-down resistor used. Together with the pin's sink/sink current, it may cause the pin's actual voltage to shift to an undesirable level. In other words, you need to make sure the pull-up or pull-down resistors are strong enough.
If you choose to drive the pins in active mode, make sure that the drive strength is good enough for the CMOS load you are using. If this is not the case, the noise surrounding the circuit may be strong enough to exceed the drive signal, forcing the pin to go into an unexpected state.
Let's study several situations:
1. The processor that works in the lab may not be restarted in the field because the noise is coupled to the RESET line that does not have a strong pull-up resistor.

Figure 3. Noise is coupled to the RESET pin with weak pull-up resistor, which may cause the processor to restart


2. Imagine the case where the CMOS input belongs to a gate driver that controls a high-power MOSFET/IGBT that turns on unexpectedly when it should be turned off! It's just terrible.

Figure 4. Noise Overdrive A Weakly Driven CMOS Input Gate Driver Causes High Voltage Bus Shorts

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 the intermediate level for a certain period of time, causing various problems.

Figure 5. CMOS input rises/falls very slowly, causing a temporary short circuit during transitions
We have discussed some issues that may occur with CMOS inputs in a general sense. It is worth noting that some devices are better at handling these issues than others in terms of design. For example, devices with Schmitt trigger inputs can better handle signals with high noise or slow edges.
Some of our latest processors have also noticed this problem and have taken special precautions in the design or issued clear guidelines to ensure smooth operation. For example, the ADSP-SC58x/ADSP-2158x data sheet makes it clear that some pins have internal termination resistors or other logic to ensure that these pins do not float.
Finally, as everyone often said, it is very important to finish all the finishing work correctly, especially the CMOS digital input.

More electronic products：theperseids