nRF52832 GPIO irreversible pin damage in application when used as a momentary switch sense input

[Protonert]

In my product I use certain GPIO pins configured as input with the pull up activated to act as sense inputs connected to momentary switches to control the application firmware.

Recently I had several incidents from my customers and fellow developers where GPIOs became irreversibly damaged.

In each case a GPIO involved was connected to a momentary switch (i.e. a mechanical switch between GPIO pin and GND).

The application worked fine until the point of breakdown, which means the GPIO was correctly configured as input with a pull-up.

After the damage the pin is stuck to GND. The devices affected have an increased current consumption (normal deep sleep current is ~150uA, which goes up to several tens of mAs for damaged chips.

In the application we use one or two momentary switches. On the one the momentary switch is depressed approx. 1% of the time in active mode. The other is depressed 10% of the time. Latter is more prone to an earlier breakdown, i.e. the degradation happens during the on state of the momentary switch, until the point of breakdown.

As using a momentary or latching switch on a GPIO is a standard use case for microcontrolllers, I would like to understand what could possible cause such damage.

The incident is unlikely related to my product and is also reproducible on a reference device (Adafruit nRF52 Bluefruit), therefore dependency on layout of board or influence of additional peripherals I can rule out at this stage.

[Kenneth]

I think the best I can do here at the moment is to offer you a schematic and layout review if you haven't already performed that. It is very important that any GPIO is always within >GND-0.3V and <VDD+0.3V, so make sure that you have not connected inputs somehow to different power domains, though I assume the button here are simply shorting to GND when pressed, so not sure how that can happen. I don't expect you have split ground here any thereby don't have some ground currents, voltage potentials here. Exceeding the stated input range may damage the chip over time (EOS damage). If you want we can perform an failure analysis on the chips.

A sleep current of 150uA was very high, I assume you have external circuitry drawing much of this current?

Kenneth

[Protonert]

Hi Kenneth,

If you wish for your internal learning I can provide a sample with the described damage for your failure analysis.

I can also send over a secured and encrypted channel the schematics and the layout for review (i.e. not in the public chat). However we did that already with no findings which could explain the damage. GPIO's are directly broken out, except a few which are connected to the gate of nMOS power drivers (but alas they are not the ones damaged). The switches simply short the GPIO to GND. We do not have splitted GND domains. Slight GND-bouncing can happen as many application cases use WS2812B neopixels, which depending on the number of LEDs can draw a few Amps. However I expect that this will cause recoverable malfunction instead of outright EOS.

Regarding the sleep current, yes, we have peripherals which also consume current during sleep mode.

[Dan Halbert]

Have you tried a static test where you ground the pins in question, with a test program that sets those pins as outputs with pullups enabled? You could let it sit for a while to see whether the pins fail.

However, you mentioned that there are potentially many RGB LEDs attached. It would be important to do the test above with and without the LEDs attached, and have them doing some kind of dynamic display to vary the display and to introduce transients. Have you seen pins being damaged with no LEDs attached?

Based on my Internet sleuthing, I believe these may be LiPo-powered devices. Are the board and the LED strings powered from the same battery? Is there charging circuitry integral to the product?

If this is not a battery-powered device, I would note that we have seen some 5V supplies that produce substantial spikes when powered up. This can damage the LEDs, though we have not heard of microcontroller output pins being damaged.

[Protonert]

Hi Dan, yes I did try a static test, even a cycling one with repeatedly pressing the button. However the chance of reproduction there is meager at best, since the exact root cause can only be guessed at. Same story with the duration of the stress.

The most important question is if such a damage is caused by something intrinsic or extrinsic to the board/controller.

It is hard to tell if the damage can happen with no LEDs attached. The LEDs are not attached to the damaged pins, but are programmed by other GPIOs. Although these LEDs, if there are many of them (we talk about 100-300) can cause considerable currents to flow, that alone does not explain a damage to an unrelated pin.

Yes, your research took you in the right direction, we are talking about Li-Ion powered portable devices. Charging circuit is part of the board. The LEDs are of course powered by the same Li-Ion battery as the board. We never use 5V on such LED strings, they can work reliably even below 3V...

[hmolesworth]

Longshot, but you might consider inductive flyback due to the LEDs; the LEDs themselves have tiny inductance, but not so the interconnect wire which can be significant. Usually in an industrial application long wire runs or coils are run by using non-inductive layout. With a coil (such as a miniature sensor heater) this is done by folding the wire at the halfway point and wrapping the coil so the outward current path matches exactly the return current path. With a long LED string this is also of benefit, run the outward wire (3 volt drive)  along (better still twisted with) the return current wire (typically the Gnd). That works only if the string uses an out-and-back pair of wires in a literal string; a star or ring layout is of course not so simple, and an out-only with some kind of distributed Gnd return is also a problem.

So a test; make an LED string using the same number and type of LEDs with a twisted pair supply and return and see if there is still a problem.

Fallback solution if this non-inductive configuration is not possible with your layout - try a reversed-bias schottky diode at the start of the LED string between the driven pin and Gnd. This may work as the inductive flyback spike radiated or conducted when the LED current is interrupted will couple a negative voltage pulse to the push-button lead and (if the push-button is closed) also to the input pin which will turn on the internal schottky clamp diode in the nRF52 and hence cause it to break down. A small capacitor on the input pin may also provide some limited protection.

The schottky clamp diode needs to be on the LED drive and return at the nRF52 end, not the push-button input pin. These notes apply even if there was no problem; inductively radiated noise should preferably be suppressed as they can (and will) affect other devices in close proximity.