Take you to explore the low-power design of MCU

After Embedic published "Understanding Microcontroller Unit (MCU) in 1 Minute"  many people sent emails, asking questions about MCU and other questions. Today, combined with the actual case, Embedic will take you to continue to explore the low-power design of the microcontroller. After years of low-power hardware design, embedic found that one of the easy problems is that the IO is not properly configured before the MCU enters sleep mode. The main problem on the product is that these problematic IOs are relatively hidden. After many tests at that time, The probabilistic power consumption problem was discovered later in production or on-site without testing. From the perspective of hardware, I recently realized that a bug that has always been easy to make in the original software is that all IOs are not reconfigured before going to sleep, which easily leads to the appearance of IO low-power BUGs.

The summary of this experience is: it is required to configure all the IOs of the single-chip microcomputer used from 1 IO to 1 IO in the code before entering the sleep mode. Don't be lazy, don't configure multiple IOs together.

Analysis:

Peripheral clock

The peripheral clock is not turned off, the internal modules of the single-chip microcomputer are not turned off, etc. Some single-chip microcomputers will automatically turn off after going to sleep, and some will not automatically turn off. So these have not had any problems in actual production.

IO configuration

One IO is connected to one IO configuration. Do not configure multiple IOs together like BIT1|BIT2……, |=0xxx. Because the more intuitive the code, the lower the probability of clerical errors. And when we check IO, it is IO one IO to check the configuration right. So writing the code one by one does not take much time and code space. It takes 5 to 30 minutes to die, but the time and money saved later is hard to say. Humans are always lazy. When I wrote the code myself, I only configured part of it before entering low power consumption. Now I slowly start to get used to all the configurations. Many configurations can copy the previous IO initialization (this has already developed 1 IO, 1 IO configuration, it is actually very comfortable to change).

Case

The most troublesome and most insidious situation that actually occurs is often related to the IO configuration. The simpler it is, the easier it is to cause problems.

1. For example, in most cases, the IO configuration is no problem after the program enters sleep from the A subroutine, and no problem is found after a lot of testing. But when you go to sleep after B is executed for a certain time, the IO is operated in B, and the IO is not changed back when you go to sleep, then the problem may occur. And if you execute C, D... and wait for the program to sleep, there will be no hidden danger of IO.

Case: The product is found to the customer that about 50% of the battery runs out after being left for a period of time. The research and development was puzzled. I checked the code many times and found no problems, and there was no crash problem before (after the crash, it will cause low power consumption and high power consumption). I sent someone to the field to test. After a lot of tests, I found that an IO part has a high output. The current is about 1mA more. The reason is that the customer did a second pulse output after powering on, and the product was powered by the battery after power off. The customer did not configure to turn off the second pulse output before powering off, and did not configure the IO back after the program was powered off, resulting in a 50% probability that the IO output was high.

2. Tens of thousands of units have been produced for one product, and no problems have been found. Later, after changing to a PCB manufacturer, the production found that the power consumption of individual products was about 10uA higher. The research and development took it back and analyzed it and found that it was just fine if the chip was changed. However, if a few percent of the power consumption is not good in production, the chip cannot be damaged with such a high probability. 430 chips, from regular suppliers. After searching one IO one IO, I finally found that an IO connected to the optocoupler input terminal was configured in input mode by touching the IO. The chip was replaced because it was soldered, the board became dirty, the resistance became small, and the IO has a relatively fixed voltage biased to GND, so it is no problem. There was no problem before. Maybe the resistance of the board was a little lower than that of the current one, or the humidity was higher when it was produced, or the reverse leakage current of the optocoupler was higher. It is also possible. The software found that this IO was originally configured without any problem, and I didn’t know where it was configured or accidentally even configured this IO when configuring other IOs. In short, I didn't find any changes to the configuration of this IO at the time, but reconfigured the IO before entering low power consumption.

3. The IO problem of an outsourced low-power RF module used on the product. Use CC1101 and 430F2132. They are all low-power chips. I found 2 development modules before and after. The first 2132 had not configured an IO. It was found that some products had high power consumption during the production stage. Later, because of the leadership, it was changed to a wireless manufacturer to do this, which was the CC1101+2132 solution. It stands to reason that you should learn from the mistakes you made before. And the software staff are also veterans. As a result, the production was no problem, and some product problems were still found when shipped to the customer. Finally, it was found that an IO was not configured properly.

4. The experience is very simple, but it is a painful experience gained from spending many times and money. And these are all software problems, but the power consumption problem is often the first to find the hardware: the product you design has a high power consumption, and the battery is dead, you can check to see where the problem is. Those who do the hardware can't open the code, and the software personnel often don't admit that there are problems with the IO configuration, especially the modules developed by outside manufacturers. They mean that I have been making software for many years. After developing so many products, how could something go wrong with such a simple product? It is the problem that your own product did not make. Hard-working hardware engineers have no choice but to find the problematic IO by themselves. The software staff completed the code comparison test, but the software still won't say that there is a problem with the code.

5. Questions about IO. 430 MCU IO settings are the weakest. Most of them do not have pull-up and pull-down resistors. The default is the input state. Without IO configuration, power consumption is prone to problems. ST's are relatively good. The default 51 state of 51 IO has pull-up resistors. The unused feet will not cause problems if they are not configured. I used to configure the empty IO to output 0 state. I recently read the code with STM8S and found that I like to configure it as a pull-up input state. STM8S has no pull-down resistor. STM32 has it. It is better to configure it as a pull-down input state. Will output current externally.

Embedic is a website that specializes in providing information related to embedded technology. Embedic use a complete embedded product supply chain and intelligent Internet technology to build an information database, and provide customers with all product data about embedded technology and product documentation. Manufacturer information and application solutions,You can check Microcontroller Unit for more MCU content.