Issue with NRF51 unexpectedly entering debug mode


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

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

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


  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?
  • @Jarmo, We have not succeeded in capturing the event that is causing the NRF51 to enter debug mode. I'll keep this thread updated if we find any more information.

  • I am investigating a similar issue now. The chip appears to enter debug state (draws high currents even in system off, ignores reset pin, but otherwise behaves correctly) very rarely in cases of unusual power-on conditions. Will check for glitches on SWDCLK today. Note that the resistor on the SWDCLK line is only shown in version 3.3 of the nRF51822 PS, not version 3.1, and there is no explanatory text (which I'd expect if this is a known issue, particularly as the pin has an internal pull-down as well).

  • 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).

  • Bumping this. We can (rarley) reproduce exact the same behaviour with 1.2mA when device is doing nothing, and 4mA when we run system_off.

    The issue is triggered when you glitch the power on/off, and not even the HW reset circuit saves us since the reset is inactivated...

    Is the official solution to add 1k resistor together with 1nF shunt on the SWDCLK? Since the 1k is added in PS 3.3 i assume Nordic knows that this is a problem in practice as well and should have a verified solution

  • The reference layout (PS 3.3) uses a 1k resistor.

    When this is not enough, the suggested alternative is to remove the resistor and add the 1nF (or less) capacitor in its place. Note that using a capacitor instead of a resistor may affect programming speed, and for most designs using a 1k resistor solves the issue. Whether this change is needed depends on the particular PCB layout/casing/environment. See also the other suggestions in Kenneth's answer above.