Guidelines for design to minimize ESD-caused resets of nRF51?

RE: Guidelines for design to minimize ESD-caused resets of nRF51?

ovrebekk — Thu, 03 Dec 2015 09:34:31 GMT

A reset could happen quite easily if you are exposed to a strong ESD event, that is true. I would try adding the cap and/or pull up as described above and see if it solves the issue.

RE: Guidelines for design to minimize ESD-caused resets of nRF51?

ScottBBBB — Wed, 02 Dec 2015 15:41:19 GMT

So it sounds like it's difficult to prevent a reset from occurring, given how short a pulse is sufficient to cause it. We will have to take a number of measures simultaneously, from the sound of it. Thanks, Scott

RE: Guidelines for design to minimize ESD-caused resets of nRF51?

ovrebekk — Wed, 02 Dec 2015 12:47:28 GMT

If your part goes into normal operating mode then the ESD event has probably just caused a normal pin reset. A 0.2us pulse on SWDIO/RESET should be sufficient to reset the device.

It's hard to provide an exact limit on SWDCLK speed based on the pull strength, as this will change depending on what debugger you are using, how long the signals are, and so forth. I would expect 1MHz to work fine with 1,5kOhm pull ups/downs, but you will have to do some testing on your own to be sure.

RE: Guidelines for design to minimize ESD-caused resets of nRF51?

ScottBBBB — Fri, 27 Nov 2015 23:59:06 GMT

Hi Gustavo,

We're using an ESD gun, with direct discharges onto battery-charging contacts. The nRF51 appears to be resetting, but it immediately comes back up in normal operating mode. We have a TVS in the circuit, but obviously it's not sufficient, and we're going to modify the PCB layout to add protection on more lines. I can't share the schematic because it's proprietary to my client.

RE: Guidelines for design to minimize ESD-caused resets of nRF51?

ScottBBBB — Fri, 27 Nov 2015 23:56:33 GMT

Hi Torbjørn,

If the part gets into debug mode, how does one get it back into normal mode? I ask because the part goes into a normal operating mode after the ESD event without us doing anything.

So the use of strong pull-ups and pull-downs doesn't prevent proper use of dev tools? Is there an upper limit on SWDCLK speed when using the strong pull-up/down? FYI, there are no nRF51 I/O signals directly accessible to the outside world. The ESD event is onto battery charging contacts embedded into the plastic housing.

RE: Guidelines for design to minimize ESD-caused resets of nRF51?

ovrebekk — Fri, 27 Nov 2015 13:57:33 GMT

Most likely what is happening is that the nRF51822 is entering debug mode, as this only requires SWDIO to be pulled low while SWDCLK is pulled high, something that could happen if you are hit by an ESD pulse.

Some pointers to reduce the chance of this happening are:

Put a 1,5kOhm pull up on SWDIO, and/or a 1nF cap to ground.
Put a 1,5kOhm pull down on SWDCLK
Ensure the SWDIO/SWDCLK signals are as short as possible on your PCB. The longer they are the more susceptible they become to ESD. Rather than routing them to edge connectors on the PCB, consider using test points that you can place closer to the chip.
If possible, avoid exposing the PCB in the final product (by using a plastic casing for instance).

While it might not help you at the moment, the nRF52 chip has been designed to avoid this problem by requiring a more complicated start sequence to enter debug mode.

Best regards
Torbjørn

RE: Guidelines for design to minimize ESD-caused resets of nRF51?

Gustavo - Argenox — Fri, 27 Nov 2015 08:39:23 GMT

Hi Scott,

Obviously adding ESD protection requires a bit of knowledge of what's actually happening and what's being affected. I am assuming you are using an ESD gun to simulate. Is your board failing with conducted, radiated or both?

The usual approach to protect the device is to use diodes to clamp the transients and EMI ferrite beads to anything that is outside the protection, but a shotgun approach is not very efficient. Note that sometimes we've found that devices by some manufacturers don't actually work as well as they're supposed to.

The lines to watch out for are:

VCC Power line
Reset line
GPIO to a lesser extent

Do you know specifically what your system is experiencing? Would be helpful to have schematics and better feel for what exactly you're seeing. Feel free to contact me directly at info@argenox.com