Could heat "degrade" microcontrollers to have higher sleep current - Page 1
Forum section: electronics / projects

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: March 05, 2023, 10:08:07 am
content: Greetings allI have recently designed these boards for a hobby project. I am not very experienced with soldering SMD parts and I have poor spacial skills. Because of this I had to spend quite a lot of time with the soldering iron to solder the first few boards (it eventually got easier as I got used to it).Now I am noticing something weird. The same code running on two different boards is presenting vastly different sleep current. On one board which was reworked the most, I can only get a sleep current of 80uA but with the same code I am able to get 15uA on another board (both identical, had MCU+radio+temp sensor and switching circuitry). I have been able to get 1.8uA sleep current on a board with just the microcontroller and a few LEDs (this board was one of the newer, with quick drag soldering and reduced duration of exposure to heat).TLDR;What I am wondering is, could the microcontrollers have been "degraded" in some way to have higher sleep current? I have exposed them to my soldering iron tip for varying durations of time and they present extremely different sleep currentsThe boards themselves are quite simple, just an STM32G0 microcontroller, and a nRF24L01+ radio module and a DHT22 temperature sensor (not shown in picture). The code is simple enough, generated using STM32CubeMX, using internal HSI and LSI, using RTC to wake up from standby mode, no pullup/pulldowns, all pins in analog mode.

author: iMo
author_rank: Super Contributor
timestamp: March 05, 2023, 10:12:13 am
content: Yes. Also the pcb may change its isolation properties, moreover when not cleaned properly the soldering flux residua can cause excessive leakage currents too..

author: Someone
author_rank: Super Contributor
timestamp: March 05, 2023, 10:13:11 am
content: Cleanliness of soldering job:https://www.eevblog.com/forum/projects/leakage-current-through-flux-residue-repeatability/When chasing high impedances you need really clean results (fingerprints can be enough to throw out sensitive designs).

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: March 05, 2023, 10:28:43 am
content: Quote from: imo on March 05, 2023, 10:12:13 amThis is absolute news to me! I never imagined the PCB itself could change in any way due to the assembly process. But it does make sense once I think about it. All the heat from the soldering iron must surely have introduced some changed but I don't think I have a way to test this. For now I think its best to consider the microcontroller itself the culpritQuote from: Someone on March 05, 2023, 10:13:11 amI did have a hunch about this one, so I cleaned the boards with paint thinner to get the flux out. Its that inexpensive solid brown kind of flux, quite difficult to get off even with alcohol, once it burns.Fingerprints though, that's something I never considered.

author: voltsandjolts
author_rank: Unknown
timestamp: March 05, 2023, 10:39:31 am
content: I suspect you have one or more floating MCU input pins.All input pins should be pulled high or low, either by external hardware (your board looks not fully populated yet) or by internal pull-up/downs.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: March 05, 2023, 10:48:47 am
content: This suggest a leakage resistance of 51k Ohm:>>> 3.3/(80-15)/1e-6 = 50769.23And that is a quite low resistance. It's nowhere near the "high impedance" that you would usually associate with thoroughly cleaning PCB's.Damaged PCB's can get conductive, but that's usually because of the black stuff that contains free carbon and only happens when a lot of magic smoke has been released.The "no clean" fluxes are difficult to get of your PCB, If you clean the PCB with IPA they usually leave a ugly white powdery residue. Acid based fluxes can be conductive but are also much easier to get off the PCB.Electrolytic capacitors are also a notorious source for leakage current, but I don't see any (yet) on your PCB.It's also quite possible one of the IC's has some ESD damage. As far as I know most of the ESD damage does not result in complete loss of function but in degraded performance and leakage.Leakage current also has a significant temperature coefficient. It doubles with each 10 degrees centigrade. But that is both gradual and reversible and it's not your problem here.

author: Miti
author_rank: Super Contributor
timestamp: March 05, 2023, 11:13:37 am
content: In that package, with a good soldering iron, very unlikely. The board would be scorched if you put so much heat to damage the die through those tiny pins, in that plastic package. In the oven, yes, but then if you get to that point, you’d probably have some completely non functional and not only having higher stand by current. As others mentioned already, look somewhere else, floating pins, cleanliness, caps, etc.Also, where did you buy the STM and the NRF modules from?

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: March 05, 2023, 01:23:27 pm
content: Quote from: voltsandjolts on March 05, 2023, 10:39:31 amAll pins are set to "analog" mode and all internal pullups and pulldowns are disabled before going to sleep. Let's just hope the MCU is actually running those instructionsQuote from: Doctorandus_P on March 05, 2023, 10:48:47 amYes I too agree that ~51k impedance is quite low and not something that would be seen with flux (I would imagine maybe a meg minimum). Still there is no obvious current path now that flux has been cleaned.I think ESD damage may be quite likely. My soldering iron causes the LEDs to light up and I would have shorted the PCB ground to my body often, while soldering (no earth pin doesn't help either). I have just realised that every subsequent rework of the board yielded a higher and higher standby current. Dunno why it didn't strike me as odd earlier.Quote from: Miti on March 05, 2023, 11:13:37 amHeat was a starting point but I think I will have to agree with you. It is seeming more and more that the culprit may be ESD damage from the iron.I bought the STM chips from thishttps://evelta.com/website. Paid ~1.2$/chip. NRF modules were bought a few months ago but I cannot recall

author: Siwastaja
author_rank: Super Contributor
timestamp: March 05, 2023, 01:25:46 pm
content: Most likely a software thing after all (floating input pin). Try moving your fingers around the thing, touching pins, or just hovering a charge comb or a cat over the circuit and see if sleep current changes.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 05, 2023, 01:27:42 pm
content: Quote from: BadeBhaiya on March 05, 2023, 01:23:27 pmTry enabling a pullup, a puldown, or externally tie the pins to Vcc or GND, on all pins. One could assume the "analog" mode solves the problem, but maybe not, or maybe it's not available on every pin.

author: temperance
author_rank: Super Contributor
timestamp: March 05, 2023, 01:32:49 pm
content: @ SiwastajaQuoteFor very large boards, one can also use a dog. Preferably one with long hair.Once the offending area has been located, switch to a mouse for more accuracy.Priceless advice

author: voltsandjolts
author_rank: Unknown
timestamp: March 05, 2023, 01:40:08 pm
content: Measure voltage of each MCU pin while watching the standby current.If you have a floating pin problem, the 10M-ish voltmeter input should 'fix it' temporarily, or at least change standby current if multiple pins have a problem.

author: Kalvin
author_rank: Super Contributor
timestamp: March 05, 2023, 01:44:21 pm
content: Create a simple spreadsheet where you list every GPIO pin, clock and peripheral block state and mode when the device is running and when the device is in sleep state. Then check your code that it is really configuring the pins, clocks and peripheral blocks as intended. This will keep you working in a systematic way.

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: March 05, 2023, 02:57:02 pm
content: And the plot thickens!I did some tests with a few boards with minimal components. They may visually look slightly different but they have the same basic components, the MCU itself, an LED(s) and respective current limiting resistors and a reset button. No decoupling caps, nothing else at all. Notice that the board #4 does not have the reset button (important later)I first cleaned them all using some fresh paint thinner and a ball of cotton. Surprisingly even clean looking boards can have a lot of flux on their surface. I then flashed them all with the same exact code which ends by putting the MCU in standby mode. I then connected them to my NRF power profiler board and let them run until they went to sleep in a few seconds at 3V.The numbers you see on the image are the average sleep currents of all the boards. The normal "active" current of all boards are similar around 600uA but interestingly, on the boards with higher current consumption their sleep current is somehow higher than or just marginally lower than their active current. There is also a lot more "noise" in the current waveform on the boards with high current consumption. I cannot be certain if they're actually sleeping or not but I assume they are since they do not respond to the STLINK debugger when they sleep (which they do after just being reset)Board #4 is the only one with current consumption that is even remotely passable. It is strange since it has spent more time with the soldering iron and I even found a solder bridge between two pins (pin 2 and 3, not being used). It was also the only one without a reset button which led me to suspect if the insulation on the reset button was the culprit (it wasn't, I removed the button from the #5 board and the current consumption somehow jumped to 800uA in sleep)I'm perplexed by this issue but I wouldn't have it any other way.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: March 05, 2023, 03:22:48 pm
content: Quote from: BadeBhaiya on March 05, 2023, 02:57:02 pmThat is a very bad Idea.Without any decoupling capacitors, weird things can happen, especially when you have long leads to the power supply. At the very minimum, you should have at least one ceramic decoupling capacitor on the board, even for testing. For normal runs, it used to be recommended to put 100nF near each Power & GND pin pair, and this usually is still plenty, unless you get into stuff with very high clock frequencies, then decoupling becomes more complicated.For what floating inputs can do, just program a bunch of I/O pis as input, then connect them all together, and connect a potentiometer to it. Then adjust the input while keeping an eye on the current consumption. It is likely you will see a peak in current consumption when the voltage of those pins is near to half the supply voltage.Is there any firmware in these things running at all? Common ways for reducing current consumption from I/O shoot through is to enable internal pullups, or to set the pins to output. But if you want to know for sure, then read the datasheet and application notes.

author: tggzzz
author_rank: Super Contributor
timestamp: March 05, 2023, 03:50:16 pm
content: Quote from: BadeBhaiya on March 05, 2023, 01:23:27 pmIs that what the data sheet an application notes recommend?Why wouldn't the MCU run those instructions?Inputs should never be left floating.

author: wraper
author_rank: Unknown
timestamp: March 05, 2023, 03:56:16 pm
content: Sounds like crappy flux.

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: March 05, 2023, 03:58:09 pm
content: Quote from: Doctorandus_P on March 05, 2023, 03:22:48 pmIf it was a floating pin issue, I think it would've been present in all boards and I wouldn't have the one with 2uA. Nevertheless the potentiometer method sounds good, I shall try it out.The boards are programmed to sample the DHT22 sensor, then initialise the NRF24L01+ radio module and finally transmit the readings and go to sleep after turning off the DHT22 and radio module voltage rails using a CJ2301 PFET. The code runs well and I have 2 boards which have been transmitting 24/7 for a few days.The boards too "work", its just that their current consumption is way higher than expected.Quote from: tggzzz on March 05, 2023, 03:50:16 pmYes the application note recommends to set the pins as analog. No pins are left as floating. All pins including the SPI pins are set to analog modeRegarding the MCU instructions, that was just a joke. I'm pretty sure the code is running fine

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: March 05, 2023, 04:36:26 pm
content: Quote from: wraper on March 05, 2023, 03:56:16 pmJust out of curiosity i removed a faulty MCU off a board (i forgot reverse polarity protection and put the battery other way around) using hot air gunLets just say I shall never be using this flux again

author: Siwastaja
author_rank: Super Contributor
timestamp: March 05, 2023, 04:40:12 pm
content: Quote from: BadeBhaiya on March 05, 2023, 03:58:09 pmNo, floating pins float to whatever voltages, even gigaohms of flux residue can resolve the levels close enough to Vcc or GND for this not to matter. But if the pins end up near the middle of the rails, and digital input stage is not disabled, large current (like hundreds of µA) will flow. You absolutely must make sure you don't have floating input pins.It would be typical to see some boards working and some not due to floating pins, depending on what voltages the contaminations pull the pins to. If uncontaminated enough, then the pins will just pick up any random static charges (hence hovering the cat over the board changes things).You absolutely must add the decoupling caps, to each Vcc pin. Don't even try without, anything random can happen, you are wasting your time.

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: March 05, 2023, 04:55:44 pm
content: Its clear to me that I must look further into status of the GPIO pins on the MCU.Thank you everyone for your time, I shall update this thread with anything I find.

author: temperance
author_rank: Super Contributor
timestamp: March 05, 2023, 05:18:30 pm
content: Also check the debug interface. Does it have pull up/pull down resistors.Also check what happens if you put the MCU in sleep mode while debugging. It might not go into sleep mode.

author: ejeffrey
author_rank: Super Contributor
timestamp: March 05, 2023, 05:19:43 pm
content: Quote from: tggzzz on March 05, 2023, 03:50:16 pmYou should follow the data sheet but often it is OK or recommended to leave analog input pins floating. Generally analog pins will be routed to non-selected inputs of the sampling mux which is the source terminal of a MOSFET not the gate.Obviously check the data sheet and application notes for a particular processor but this is a very common configuration.

author: Terry Bites
author_rank: Super Contributor
timestamp: March 05, 2023, 05:42:58 pm
content: Its nice to believe that if treated kindly all semiconductor devices will last forever.You can hear all the little fist pumps from the manufactures echoing in the distance.

author: temperance
author_rank: Super Contributor
timestamp: March 05, 2023, 09:20:23 pm
content: Here is a nice app note which tells you exactly what to do with each type of pin.https://www.st.com/content/ccc/resource/technical/document/application_note/group0/13/c0/f6/6c/29/3b/47/b3/DM00315319/files/DM00315319.pdf/jcr:content/translations/en.DM00315319.pdf

author: wraper
author_rank: Unknown
timestamp: March 05, 2023, 10:01:50 pm
content: As I said, most likely it's a current leakage thorough the crappy flux, and vastly different consumption of boards is a strong indication of that. Otherwise even if increased, it would be similar. Before trying to do anything with firmware, you need to rule out that. Does the board with MCU removed but with flux left consume current?

author: BrianHG
author_rank: Super Contributor
timestamp: March 06, 2023, 04:08:42 am
content: Most of my ultra low current projects required ultrasonic cleaning of my PCBs to get the lowest currents.Under microscope, you can clearly see micro grains of solder tin caught in the flux inbetween adjacent IO pins resistively pulling them high or low against my driven OP settings when I set the processor into ultra low power down. I've seen current as high as 1ma before cleaning and down to the proper nanoamps after. Note that old fashioned leaded solder was nowhere near as bad as lead free, no clean flux variants.Before I had an ultrasonic cleaner, I did use an ultrasonic vibrating electric toothbrush with both both a super strong cleaner, then a flux remover, then water. It was a hassle to truly clean the pcb, but once done, the excess current was gone.*** Also, leave no IO floating. Always have every IO tied to GND or VCC, or, drive them to GND or VCC, or make sure if you have weak pull-ups enabled, that those IO reach VCC completely at rest for the least amount of current draw.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 06, 2023, 06:05:41 am
content: Quote from: wraper on March 05, 2023, 10:01:50 pmWhile I agree flux is the most likely cause, you should fix all the usual culprits at the same time, not one by one. 1) flux, 2) floating IOs, 3) adding missing decoupling caps. These are things that all likely cause trouble so if you fix one by one, similar problem mysteriously then comes back later, wasting more time.

author: iMo
author_rank: Super Contributor
timestamp: March 06, 2023, 07:40:57 am
content: QuoteI would not use the paint thinner (!). Use a 99.5-100% IPA (isopropyl alcohol) instead. Put the board into the IPA and let it be there for a night, such it dissolves the crap beneath the chip (do use a closed clean jar).. Then wash the board again with fresh IPA and use a clean toothbrush (I do it several times sometimes (like 4-5x), always with a fresh doze of IPA). No residua shall remain on the board, it should be perfectly clean finally.PS: a hint - the IPA consumption during cleaning is rather high - buy several liters of it when producing a larger series of boards as you do..

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: March 06, 2023, 10:10:44 am
content: So an update, seems like my hardware itself is indeed fine!I generated a small new CubeMX project to test the hardware with the bare minimum, just the RTC enabled to wake up every 20s from standby sleep and the GPIOs (to control the LEDs and the PFETs to switch the radio and temperature sensor) and wrote a small blinky type test firmware. The result can be seen, I can get a 2uA sleep current.It seems like there was some wacky repeated interrupt calls which where messing with the original code. Its strange, maybe I was not disabling the appropriate interrupts properly while sleeping

author: voltsandjolts
author_rank: Unknown
timestamp: March 06, 2023, 10:41:22 am
content: What current data logger are you using?

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: March 06, 2023, 11:39:39 am
content: Quote from: voltsandjolts on March 06, 2023, 10:41:22 amIts an nRF Power Profiler

author: bookaboo
author_rank: Frequent Contributor
timestamp: March 06, 2023, 02:45:49 pm
content: I had an interesting sleep current bug involving a uart once. We build an upgraded test jig for a mature product line, 50% of the devices failed the new sleep current test by creeping from 20uA up to 30uA. After much investigation we tried some parts from an old batch, these had the same issue. Since it appeared they has always been that way and 30uA was well within the customers spec (<100uA) the "pass mark" was adjusted and the line ran well from then on.The interesting part, we had some firmware updates requested and the sleep current always bugged me. I attached a power logger and noted that he current crept up in very small steps then would drop down to 20uA again. This was intermittent, checked all the pins were set as outputs and driven low during sleep, which they were.I finally figured it out when I increased the uart buffer and the 30uA turned to 45uA.The "debug rx" pin was left as a floating input, on some boards it would pick up noise and fill the buffer. As it was an old PIC16F part, everything was bare bones, there was no flush on the buffer until it got "CR" or overflowed. The "30uA" came from the device waking every 1s (as it should do) but spending a few uS parsing the uart buffer, getting nothing and going back to sleep. As the buffer filled it took longer to parse.I made the uart buffer a little more robust and made the "debug rx" pin an output in normal operation for good measure. Problem solved.Perhaps try an even more barebones firmware. Everything off except a 1mS blinky every 5mS (just to show you are alive).