My MCU's GPIO (input) voltage cannot stay pulled up

[Saimoun]

Hi!

I have 10 mounted PCB's which are identical - all working fine.

Then I am doing some shady stuff - basically I have to exchange 2 traces on my PCB, so I cut the traces, scrape the soldermask off the trace to expose the copper, and then solder small cables to have the things connected where I want them (i.e. instead of ordering new PCB's). I checked the board with the continuity meter and everything is connected where it should be.

FYI, these traces are directly connected to the MCU GPIOs.

On the first 2 boards everything went fine, but on the last 3 I keep destroying the MCU, always in the same manner: one of the 2 inputs (always the same actually) looks dead. The input is simply connected to a switch with an internal pullup. When I power the board it starts at 3.3V, then drops to like 1V, then sometimes even lower (and it keeps going up and down, like if it was "trying" to get back up).

My guess is ESD - so for the last board I was extremely careful, had a wrist band connected to the circuit ground, was wearing 100% cotton clothes, and was generally not moving much when doing things with the traces. But the board still got the same issue.

My questions are:
1) Do you also think it is ESD or could it be something else?
2) I tried deactivating the internal pullup and just solder an external one (about 7k), and surprisingly the voltage still drops - it's like the input is somehow leaking current to ground - can someone explain?

Thank you!! 

[ggchab]

Some questions/ideas
What is the reason to swap the 2 input pins ? Or was one one an input and the other one, an output ? One is a switch. But was is the other one ? Did you adapt the firmware to the pins swap ? Did you re-flash the MCU on all boards ?
Is the GPIO really dead ? Can you see some activities on other GPIO pins before the voltage drop ?
Remove the added wires. Voltage still drops ? Check the pin I/O with a dedicated firmware, ...

[Saimoun]

Thanks for the reply. Yes the firmware has been updated.

I exchanged them because I need to use the second comparator in my MCU, and when I designed the PCB I missed that it can only be used on certain pins  (for my defense that info was pretty hidden...). There are clearly software ways around it, like using the ADC instead (which can be used on all pins). But I thought a simple exchange of traces should be easier than rewriting the code (also because at some point I'll get new PCB's with the correct traces anyways).

The mafunctionning pin is connected to a switch which is normally open and I checked the wire is not connected to anything else, like ground.

I am not sure what you mean by activity - the GPIO is an input, so nothing happens unless I press the switch. I can try setting it to output, which I am pretty sure will work.

[ggchab]

I just wanted to know if there was some firmware activity by checking levels on any other output pin. The voltage could only drop after some configuration change. This might help you identify which change.

[Psi]

Are you sure the trace was cut,  just cutting the trace with a knife does not always work.
Sometimes you get a fragment of copper bridging the gap.

When I need to cut a trace I usually make two cuts next to each other and pry up the section of copper between them.

[perieanuo]

Are you sure the trace was cut,  just cutting the trace with a knife does not always work.
Sometimes you get a fragment of copper bridging the gap.

When I need to cut a trace I usually make two cuts next to each other and pry up the section of copper between them.

i agree, happens to the best of us, but multi-meter sees this in 2 seconds
i doubt the micros i/o's are damaged by discharge done why working the pcb, we did those kind of work on regular basis in one company (the hw designer was sloppy and always forgetting some modification, so go cut/modify the trace...), never had esd blowing uo dsp/microcontroller pins.
of course, the mod was done without the module attached to his power supply, even the ground can make you difficult times (the words 'galvanic isolated' comes in mind in this case).
maybe as you're pointing, the op didn't checked if the trace is really cut entirely and put the juice on, in this scenario you burn the 2 i/o's with one hit

[cgroen]

Does this also happen if no code is loaded into the CPU ?

[Saimoun]

Thank you all for the replies.

@ggchab: fair point But the voltage drops really weirdly and very unsteadily, not like something moving cleanly from 1 to 0.

@perieanuo: interesting to hear, I thought it was only me doing this kind of weird stuff, I thought most people would simply buy a new PCB!
But I did check with the multimeter and everything was connected where it should have been.
And even if the two IO's were still connected that should not blow anything since they are configured as input when the MCU starts, and stay in input.

And yes I did all the PCB work with the power disconnected, and with a wrist band attached to the circuit ground.

So if you do not think it is ESD what could be happening?

@cgroen: I can upload an empy code, but that would just leave the IO's at default which is input so the voltage would just stay at zero

[cgroen]

...
@cgroen: I can upload an empy code, but that would just leave the IO's at default which is input so the voltage would just stay at zero

fair enough, I was just thinking if the default state was input with pullup enabled on the CPU (which it is on many brands/types).
Good luck finding the bug!

[Psi]

Are you sure the trace was cut,  just cutting the trace with a knife does not always work.
Sometimes you get a fragment of copper bridging the gap.

When I need to cut a trace I usually make two cuts next to each other and pry up the section of copper between them.

i agree, happens to the best of us, but multi-meter sees this in 2 seconds

True, but the copper fragments can cause intermittent shorts in the gap.
Safest option is to pry up a little track, or use microscope if you have one to confirm a cut .

[Psi]

ESD is like lupus,

It's never lupus.

[Saimoun]

Ok so the strange thing is... now it seems to work

So actually the theory of small copper fragments could be true, not on the cut of the traces (because as said these are both inputs so it would make no difference), but on the ground pour next to it (which should still be covered by soldermask but maybe I uncovered just a tiny bit of it?).

Still strange the voltage dropped to like 1V'ish and not zero if it was a small copper fragment connecting it to ground... 1V that means the fragment would have a resistance of about 16k ohm?

I will test the other 2 failing boards and see.

[Saimoun]

Ok I left it long enough and yes the voltage started to drop.

It's almost like if the MCU gets "tired" and since it had a few days of rest it was working for some time today 

See attached screenshot - the voltage is supposed to stay steadily at 3.3V. The drop to 0V is me pressing the button.

[rcbuck]

You haven't mentioned the MCU that you are using. Is it a Microchip part that has the pins enabled as analog pins by default? If so, you must change them to digital IO pins at startup.

[thm_w]

Post a photo of the mods, schematic, and the configuration code used to set up the IO.

[radiolistener]

Usually there are three possible issues:
1) the pin is burned out due to mains voltage on the soldering tip (for example through GND mains connector).
2) the wire used for jumper is too long and sucks a lot of noise from a noisy environment.
3) there is some hidden contact between the pin and GND/VCC or some signal.

Did you tried to remove all wires and test the pin with testing firmware?

[mikerj]

Internal pull-up not correctly enabled and the pin is floating.  Which micro are you using, and which pin is it?

[Saimoun]

Thank you again for the answers.

MCU is an STM8L151. Pull-up is definitely enabled, and I got similar results with an external pullup. Like I said nothing is actually connected to the pin (since it's only an open switch), but I can double check.

@radiolistener: your "1)" is very interesting, never heard about that before? I do not have an earth wire on my iron, does that affect it?

[Saimoun]

And again after "resting" over night the pin is steady at 3.15V now - let's see in 15 min it will probably start to drop like before.

[ggchab]

Are you sure the power supply itself is not faulty ? Is the MCU heating when voltage drops ?

[Saimoun]

It has been an hour and for now the voltage is stable    I am also trying to "stress" the pin - I read that if it is ESD, sometimes the problems only appear when the pin is stressed under normal conditions.

I checked before, the power supply is steady at 3.3V, even when the voltage was dropping. I'll have a look at the temperature.

[Saimoun]

So this time it took a few hours before the voltage started dropping again, I just left the device connect for some time alone.

See the attached graph, at -12.8s I released the button, you can see the voltage held for like a second or so, then dropped.

[AaronLee]

From the time it first dropped after the button was released, to the first spike is roughly estimating it to be 6.6s. Then roughly 2s to the next spike, then 6.6s to the next, and again 6.6s to the next. Seems too much of a coincidence to me. Something (likely firmware) is causing those spikes at the same intervals.

You're sure you tested it with the flash completely erased? Otherwise maybe your code is doing something on that port that you don't realize. If you're sure it was completely erased, is there a bootloader built into the chip, and it could be using that pin to try to boot? And is there a watchdog timer? Could it be the chip is resetting every 6.6s?

Try adding code to some other pin as an output and set a timer to toggle the pin at a fixed interval, and watch that pin. If the output is always exactly a square wave, the MCU is likely not resetting. If it isn't exactly a square wave, you can probably determine at which point the MCU is resetting, and perhaps use that to track things down.

[Saimoun]

The spikes are random - sometimes there are no spikes at all.

I am also really convinced the code is not the problem.

Here is an example with a dummy code that switches on and off the pull-up every 2 seconds (the messy bit around 0V is because without the pullup the input is floating). Now there is nothing else happening. You can clearly see that when it is pulled-up it holds to 3.3V for a few milliseconds and then drops.

I also tried switching the pin to output and going from 0 to 1 - that works perfectly fine as expected.

[AaronLee]

The spikes are random - sometimes there are no spikes at all.

I am also really convinced the code is not the problem.

Here is an example with a dummy code that switches on and off the pull-up every 2 seconds (the messy bit around 0V is because without the pullup the input is floating). Now there is nothing else happening. You can clearly see that when it is pulled-up it holds to 3.3V for a few milliseconds and then drops.

I also tried switching the pin to output and going from 0 to 1 - that works perfectly fine as expected.

Perhaps it's nothing, but on the second time the pull-up is turned off, the voltage is stable at 0V for a hundred milliseconds or so before becoming "messy".

You mentioned the MCU is a STM8L151, but didn't specify which pin you're using. I'm not at all familiar with that MCU, but if you state which pin you're using, and someone's familiar with that MCU, they might have a clue. For the MCUs I'm familiar with, you get to know the idiosyncrasies and the details of the specs, etc., so that there might be a good clue as to what it is.

I still recommend one dedicated pin (not the pin in question) as a "hello world" constantly toggling high/low line. I ALWAYS put that in my code for every project, and stick a LED on it, because it's saved me countless hours debugging strange results when either the MCU halted or it reset at some unexpected point. When you see the LED stops flashing, or flashes inconsistently, you immediately know something's wonky with the MCU.