After years of low-power hardware design (the hardware and software design in the company are separate, and I have always worked on hardware, often facing the challenges of low-power production incidents), one common issue is that the IO configuration is not set correctly before the microcontroller enters sleep mode. The main problems with the product are these hidden IO issues, which were not detected during multiple tests and were only discovered during production or on-site, leading to the problem of excessive probabilistic power consumption.
From a hardware perspective, I recently realized that a common mistake in software is not reconfiguring all IOs before entering sleep mode, which can easily lead to low-power bugs in the IO.
The takeaway from this experience is: it is essential to configure each IO of the microcontroller in the code one by one before entering sleep mode. Do not be lazy; do not configure multiple IOs together.
Analysis:
Peripheral Clock
If the peripheral clock is not turned off, and the internal modules of the microcontroller are not disabled, some microcontrollers will automatically shut down when entering sleep mode, while others will not. If not turned off, the power consumption will be high during testing, which can be immediately detected. Therefore, these issues have not occurred in actual production.
IO Configuration
Configure each IO one by one; do not use multiple IOs with similar BIT1|BIT2… |=0xxx configurations together. The more intuitive the code is, the lower the probability of typographical errors. Moreover, when we verify the IOs, we check the configuration one IO at a time. Therefore, writing the code sequentially does not take much time or code space. It may take 5 to 30 minutes at most, but the time and money saved later are hard to quantify. Humans tend to be lazy; I used to only configure part of the IOs before entering low power mode, but I am gradually getting into the habit of configuring all of them. Many configurations can be copied from previous IO initializations (I have developed the habit of configuring one IO at a time, which is quite comfortable to modify).
Case Analysis
The most troublesome and hidden issues often relate to IO configuration; the simpler they are, the more likely they are to cause problems.
1. For example, in most cases, the program enters sleep mode from subroutine A without any issues in IO configuration, and extensive testing does not reveal any 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. If C, D, etc., are executed before sleep, there may be no IO hazards.
Case:
A product was found at a customer site to have about 50% battery depletion after a period of time. The R&D team was puzzled, and after multiple code reviews, no issues were found. There had been no previous issues with crashes (which would prevent entering low power mode and lead to high power consumption). After sending someone to the site for testing, extensive testing revealed that one IO was outputting high on some products, leading to an increase in current by about 1mA. The reason was that the customer had output a pulse before powering down, and after powering down, the product was powered by the battery. The customer did not configure to turn off the pulse output before powering down, and the program did not revert the IO configuration, resulting in a 50% chance of the IO outputting a high level.
2. A product had been produced in tens of thousands without any issues. However, after switching to a new PCB manufacturer, it was found that some products had power consumption that was about 10uA higher. The R&D team analyzed it and found that changing the chip resolved the issue. However, the production still showed a few percent of poor power consumption, and the chip could not have such a high probability of failure. The 430 chip was sourced from a reputable supplier. After checking each IO one by one, it was ultimately discovered that one IO connected to the input of an optocoupler was configured as an input mode. The reason it worked after changing the chip was due to soldering, the board became dirty, and the resistance decreased, causing the IO to have a fixed voltage bias towards GND, thus not causing issues. The previous lack of issues may have been due to the board’s resistance being slightly lower than the current manufacturer, or perhaps the humidity during production was higher, or the reverse leakage current of the optocoupler was larger; there are various possibilities. The software found that this IO was originally configured correctly, but somewhere along the line, it was either misconfigured or inadvertently configured along with another IO. In any case, the configuration of this IO was not found to have been modified; it was only reconfigured before entering low power mode.
3. An issue with an externally purchased low-power RF module’s IO was encountered. Using CC1101 and 430F2132, both considered low-power chips. After working with two different module developers, the first developer 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 for the same CC1101 + 2132 solution. Logically, one would think that lessons should have been learned from previous mistakes. Moreover, the software personnel were also experienced. However, while production went smoothly, some products still had issues when shipped to customers, and it was ultimately discovered that one IO was not configured correctly.
4. The above insights are quite simple, but they are painful lessons learned through time and money. Moreover, these are all software issues, but power consumption problems are often first attributed to hardware: if your designed product has high power consumption and the battery is dead, check where the problem lies. Hardware engineers often cannot access the code, and software personnel may initially deny that there are issues with IO configuration, especially when modules were developed by external manufacturers. Their stance is often, “I have been doing software for xx years. I have developed so many products; how could such a simple product have issues?” It is your product that is not well designed that causes the problem. The beleaguered hardware engineer has no choice but to find various ways to identify the problematic IO. The software personnel complete the task only after modifying the code and conducting comparative tests, but in the end, they still do not admit that their code has issues.
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. If the IO is not configured, power consumption issues are likely to arise. ST’s are relatively better, while the 51’s IO has pull-up resistors by default, and unconfigured pins do not cause issues. I used to prefer configuring empty IOs to output low states, but recently while using STM8S, I found it better to configure them as pull-up input states. STM8S does not have pull-down resistors, while STM32 does; configuring them as pull-down input states is better, as accidental contact will not output current externally.
Aside: I had not deeply understood the low-power modes of microcontrollers before, but I recently discovered that entering the lowest power STANDBY mode causes data loss in RAM, which is not the case with 8-bit machines. 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 can allocate more RAM areas to retain data during power loss.
Author: YJGQDD (Amo: hailing), Source: Chip Home
Disclaimer: This article is reproduced with permission from the “Chip Home” public account. The reproduction is for learning and reference only and does not represent this account’s endorsement of its views. This account also does not bear any infringement responsibility for its content, text, or images.
END
