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.

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

[Protonert]

Dear hmolesworth, thanks for your suggestion, it's not a long shot at all, although I do not have so much experience with inductive flyback as you appearently have, this was also our first guess considering a pure external influence. In case the board controls a programmable LED string the most common use case has the GND wire running parallel to the power wire, with the data line in between. It would be quite a challange to twist supply and GND, our customers would not accept such a requirement. It is also not known to us that other chips have similar problems, we used 8-bit microcontrollers from other vendors for similar applications in the past.

As to the inductive flyback, we considered a bit different scenario: suppose the two wires leading to the switch form a loop/circle and the LED string connector gets inside this loop, then during fast power transients voltage could be induced in the loop formed by the switch wires. This could happen considering that in the majority of cases the wiring of the LED strings and the swicthes go in the same direction for a certain lenght.

We tried to replicate this scenario but again it's a game of chances trying to reproduce it as long as we just guess at the root cause.

Nevertheless now having your valuable input I personally would narrow down the search scope to:

1. External influence: inductive flyback external to the board/chip

2. Internal influence: GPIO port logic where both input and output directions are enabled. Here I clearly wait for feedback from a Nordic engineer to help us figure out if such a situation where both input comparator and output push/pull stages are enabled could happen.

Generally speaking I'm amazed how many good inputs are coming from the community. I would be even happier if engineers from Nordic could take a more active role in the search for a potential root cause.