Could heat "degrade" microcontrollers to have higher sleep current

[wraper]

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?

[BrianHG]

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.

[Siwastaja]

Before trying to do anything with firmware, you need to rule out that.

While 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.

[iMo]

I first cleaned them all using some fresh paint thinner and a ball of cotton.

I 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..

[BadeBhaiya]

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

[voltsandjolts]

What current data logger are you using?

[BadeBhaiya]

What current data logger are you using?

Its an nRF Power Profiler

[bookaboo]

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).