Exploring Low Power Design in Microcontrollers

After years of low-power hardware design (the hardware and software design in the company are separate, and I have always been doing hardware. Facing low-power production issues in hardware can often be quite challenging), I found that one common issue is that the IO is not configured properly before the microcontroller enters sleep mode. The main problems on the product are these hidden IO issues, which were not detected during multiple tests and were only discovered later in production or on-site, leading to the issue of probabilistic excessive power consumption.
Exploring Low Power Design in Microcontrollers
From a hardware perspective, I recently realized that a common mistake in software is not reconfiguring all IO before entering sleep mode, which can easily lead to low-power bugs in IO.

This takeaway can be summarized as: before entering sleep mode, ensure that all IO of the microcontroller is configured one by one in the code. Do not be lazy; do not configure multiple IO together.

Analysis as follows:

Peripheral Clock
If the peripheral clock is not turned off, and the internal modules of the microcontroller are not turned off, some microcontrollers will automatically shut down upon entering sleep mode, while others will not. If they are not turned off, the power consumption will be higher during testing, which can be immediately noticed. Therefore, these issues have not occurred in actual production.
IO Configuration
Configure one IO at a time; do not configure multiple IO together using similar BIT1|BIT2……, |=0xxx formats. The more intuitive the code, the lower the probability of typographical errors. Moreover, when we verify IO, we check the configuration of each IO one by one. Therefore, writing the code sequentially does not take much time or code space. Spending 5 to 30 minutes at most can save a lot of time and money later.
People tend to be lazy. When I wrote code, I used to only configure part of it before entering low power mode, but I am gradually getting into the habit of configuring all of it. Many configurations can copy the previous IO initialization (I have developed the habit of configuring one IO at a time, which is quite comfortable to modify).
Exploring Low Power Design in Microcontrollers
Case Analysis

The most troublesome and hidden situations often relate to IO configuration; the simpler they are, the more likely they are to cause problems.

1. In most cases, the program enters sleep mode from subroutine A without any issues in IO configuration, and extensive testing reveals no problems. However, if B is executed before entering sleep, and IO operations are performed in B without reverting the IO before entering sleep, problems may arise. Yet, executing C, D, etc., before sleep may not reveal any IO hazards.

Case: A product was found by the customer to have 50% battery depletion after a period of time. The R&D team was puzzled, and after multiple code reviews, no issues were found. Previously, there were no occurrences of crashes (crashes prevent low power mode, leading to excessive power consumption). After sending someone on-site for testing, extensive testing revealed that one IO in some products output a high level, leading to an increase of about 1mA in current. The cause was that the customer generated a pulse output when powered on, and after powering down, the product relied on battery power. The customer did not configure the pulse output to turn off before powering down, and the program did not revert the IO configuration, resulting in a 50% chance of the IO outputting a high level.

Exploring Low Power Design in Microcontrollers

2. A product had been produced in tens of thousands of units without any issues. However, after switching to a new PCB manufacturer, some products were found to have power consumption slightly higher by about 10uA. R&D analyzed the issue and found that switching the chip resolved it. However, the production had a few cases of excessive power consumption, and it was unlikely that the chip would be damaged at such a high probability. The 430 chip was sourced from a reputable supplier. After checking each IO one by one, it was eventually discovered that one of the IO connected to the optocoupler input was configured as input mode.

Switching the chip resolved the issue because of soldering, the board became dirty, and the resistance decreased, leading to a stable voltage bias towards GND on the IO, hence no problem. Previously, there were no issues, possibly due to the board’s resistance being slightly lower than the new one, or due to higher humidity during production, or the optocoupler having a larger reverse leakage current. These are all possibilities. The software found that this IO was originally configured correctly, but it was unknowingly modified or configured incorrectly while configuring other IO.

In summary, at that time, I couldn’t find where this IO’s configuration was modified; I just reconfigured this IO before entering low power mode.

Exploring Low Power Design in Microcontrollers

3. There was an IO issue with a purchased low-power RF module used in the product. Using CC1101 and 430F2132, both considered low-power chips. After finding two different companies to develop the module, the first company did not configure one IO correctly, leading to high power consumption in some products during production. Later, due to leadership reasons, a different wireless manufacturer was chosen, still using the CC1101 + 2132 solution.

Logically, one would think that lessons learned from previous mistakes would be applied. Moreover, the software personnel were experienced. However, even though production had no issues, individual products still encountered problems after shipping to customers, and it was eventually discovered that one IO was not configured correctly.

Exploring Low Power Design in Microcontrollers

4. The above insights are quite simple, but they are painful lessons learned from spending time and money multiple times. Moreover, these are all software issues, but when power consumption problems arise, the first to be blamed is hardware: if your designed product has high power consumption and the battery is drained, check where the problem lies.

Hardware engineers often cannot access the code, and software personnel frequently do not initially admit to issues with IO configuration, especially when modules developed by external manufacturers are involved. They often say, I have been doing software for xx years. I have developed so many products; how can such a simple product have issues? It must be that your product was not designed correctly. The struggling hardware engineer has no choice but to think of various ways to find the problematic IO. Software personnel complete the process only after comparing tests and modifying the code, but in the end, they still do not admit that their code has problems.

Exploring Low Power Design in Microcontrollers

5. Regarding IO issues, the IO settings of the 430 microcontroller are the weakest; most do not have pull-up or pull-down resistors, and the default state is input. Not configuring IO can easily lead to power consumption issues. The ST series is relatively better, while the 51 series has pull-up resistors by default. If unused pins are not configured, they will not cause issues. I previously preferred to configure unused IO as output with a low state, but recently while using STM8S, I found that configuring them as pull-up input is better. STM8S does not have pull-down resistors, while STM32 does. Configuring them as pull-down inputs is better; accidental contact will not lead to output current. As a side note: I have not deeply studied the low power modes of STM32 before, but recently discovered that entering the lowest power STANDBY mode leads to data loss in RAM, which is not an issue with 8-bit microcontrollers. Previously, I used STC’s 51 and STM8 series without worrying about RAM data loss. I noticed that the STM32L series also has this issue when entering the lowest power mode, but it allows for more and larger RAM areas to be retained during power loss.

Author: Andrei

Source: Chip Home

Warm Reminder:

Due to recent changes in the WeChat public platform push rules, many readers have reported not seeing updated articles in a timely manner. According to the latest rules, it is recommended to frequently click “Recommend Reading, Share, Favorite,” etc., to become a regular reader.

Recommended Reading:

  • How to Write a Robust and Efficient Serial Port Receiving Program?

  • If Electromagnetic Simulation Software is Banned, What Are the Domestic Alternatives?

  • Taiwan Semiconductor Manufacturing Company is Forced to Shut Down Some EUV Lithography Machines, the Reason is Quite Regrettable

Related posts

  1. Low Power Design Strategies – Resource Sharing
  2. Overview of Low Power Design
  3. Low-Power Design: Retention Cell
  4. Low Power Design: The Energy-Saving Code for Electronics
  5. Best Programming Model for Low Power Design: Asynchronous Programming
  6. Nine Key Techniques for Low-Power Processor Design
  7. Low Power Design of Autonomous Driving Chips
  8. The Four Essential Tools of ASIC Design
  9. Installing Smart Smoke Detectors Increases Escape Chances by 50%!
  10. Understanding China Unicom’s NB-IoT: Wide Coverage, Low Power Consumption, Massive Connectivity, and Low Cost
  11. The Evolving Role of Hardware Engineers in an Era of Mature Demo Boards
  12. Commercialization Solutions for Cameras in Future Autonomous Driving
  13. 5 Practical Tips for Low-Power Design
  14. Power Switch Cell in Low Power Design
  15. Low Power Design Summary
  16. Low Power Design Techniques: Power Switching Cell
  17. Detailed Explanation of Low Power Design (UPF Encoding)
  18. Overview of Low Power Design
  19. Low Power Design Focus Shifts to Reducing Power Dissipation

Leave a Comment