Issue with NRF51 unexpectedly entering debug mode

[Dave J]

Hi,

My company has been running into an issue with the NRF51822 where the MCU appears to enter debug mode unexpectedly and I wanted to see if any others had experienced the same problem.

Short story:

I've read through the messages in the forum describing the possible need for a pulldown on the SWDCLK line to avoid noise, however I haven't seen others reporting exactly the same problems that my company has been seeing.

We've seen an issue with MCUs entering debug mode without a pulldown on the SWDCLK line, and recently ran some tests with a 470 ohm pulldown and still saw a device enter debug mode.

In addition, even though the device appeared to be in debug mode based upon the current draw and operation of the device, it still responded to a pin reset, which I believed shouldn't be possible when a device is in debug mode unless a write is done to the NRF_POWER->RESET register to enable pin reset.

Long story:

1. Our device has a lifecycle of running at full power for 60 seconds, going in and out of IDLE mode for 59 minutes, and then going into STOP mode. At this point, the device would restart the cycle if a button on our device was pressed.

• While not in debug mode, the device draws ~4uA while in IDLE, and ~500nA while in System OFF.
• While in debug mode, the device draws ~1.2mA while in IDLE, and ~4mA while in what we believe is Emulated System OFF.

2. After running through a calibration test that uses BLE to connect and disconnect from the device a few times over a period of one hour, we've found approximately 1% of our devices seem to be in debug mode.

• We are sure that our devices were not in debug mode prior to starting this calibration test.
• We are fairly certain that the devices are in debug mode after the calibration mode as the current draw matches the power numbers described above, but still operates exactly as we'd expect.

3. After reading the forums, we've found other reports of devices going into debug mode due to noise on the SWDCLK line, so we put a 470 ohm pulldown on that line.

4. Even with the 470 ohm pulldown, we have found at least one device that entered debug mode while running through our hour long calibration process. Note that we do have a fairly long trace on the SWDCLK line, so we used a strong pulldown.

5. Sometimes when we find devices in debug mode, they still reset when we use the reset pin. My understanding is that this should not occur if a device is in debug mode unless a write is done to NRF_POWER->RESET.

Questions:

1. Has anyone seen devices enter debug mode, even with a strong pulldown on SWDCLK?
2. Has anyone seen a device that enters debug mode, but can still be reset via the reset pin?
3. Is there anything other than noise on SWDCLK that can cause a device to enter reset?

[Kenneth]

Hi,

The short answers to your questions are: Yes, Yes, and No.

Debug interface mode is initiated by clocking one clock cycle on SWDCLK with SWDIO=1 [See ch. 11.1.2 Debug interface mode in nRF51 Reference Manual v3.0].

Depending on layout, grounding and housing, it is not unlikely that the SWDCLK trace can act as an "antenna" and for instance, if the device is subjected to strong electromagnetic fields close by (for example a cell phone at high output power), this might be picked up.

For the majority of the applications I am aware of this is not a problem, and this is typically something developers experience during prototype stage when the bare PCB is exposed to the environment.

We recommend to add a small resistor on the SWDCLK line to make it more robust [See reference circuitry in nRF51822 Product specification v3.1]. The resistor should be as small as possible, yet still make it possible to program the chip. We have recommended 1kohm.

If you still experience that the product enter debug mode, you might consider additional steps. For instance make the SWDCLK track as short as possible, have ground on all sides of the track to avoid crosstalk with other digital lines, and avoid that it can act as an antenna. You might consider replace the 1kohm with a 1nF capacitor (or less), this might affect programming speed.

As a last resort you might even consider connect a spare GPIO on the nRF51822 directly to SWDCLK, and set the spare GPIO to output low after power up. This will prevent re-programming, so you might want to have some means for the application to release the pin.

[Carl]

No sign of a glitch on SWDCLK. However, we have observed that placing a probe on the SWDIO/nRESET pin during power-up prevents the issue from occurring (probably due to capacitance).