nrf52 cannot exit from Debug Interface Mode

[Israel]

We are using device nrf52840 with sdk 15.0.0

The problem is: High current consumption, typically around 2 mA. But over time drifts up to 9 mA in a period of 12 hrs.

1.- How to know the MCU is in Debug Interface Mode from code?

I have not found any documented source  other than comments in the forums such as:

"if (DWT->CYCCNT != 0)" Does not work for me. This is always true in my case. debugging or not debugging. Trapped in this mode or not.

"if(dgb->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk)" Works OK; if the J-Link is attached is true, false if its not attached. But the MCU can still be trapped in high power consumption (debug interface mode). Even that this register is false. So this proves that the debugger is attached, but not that the MCU is in debug interface mode.

2.- I need a reliable way to get the MCU out of Debug Interface Mode from code. (In my scenario we don't have means to power cycle it).

We need to force an exit from debug interface mode at startup, this will ensure after reset (software reset) we will not be using more power than necessary.

3.- Can we go into this mode by doing something wrong in Code? (with out debugger).

Reasoning:

We have seen in very few occasions, that our product consumes ~2mA constantly, (where it should be under 80 uA). This drains batteries really fast. 

Observations:

Software reset (NVIC or SCB->AIRCR) does not get it out of this mode.

PIN Reset does not get it out of this mode.

Using the nrjprog + J-Link to force a --reset, fixes the issue

Using the IAR IDE to connect to target and disconnect from target fixes this issue.

Power Cycle fixes this issue, however power cycling is not what I am looking for.

We can "reproduce" this issue by debugging a target, then disconnecting the debugger (j Link) with out stopping it in the IDE. It stays in this mode after resets..

In a longer overnight test, our products goes into SD_POWER_SYSTEM_OFF, which appears to get worse over time. up to 9mA. This last could be related to a component in our board, but  if we were to leave the unit when NOT trapped in this debug interface mode, then the power consumption is about 17uA. (expected)

Our quality team has seen twice this issue. They don't even have debuggers such as the JLink, They do replace batteries and claim that it happens even after swapping to new batteries too.

Please Help

Thanks.!

 

[Turbo J]

Israel said:

2.- I need a reliable way to get the MCU out of Debug Interface Mode from code. (In my scenario we don't have means to power cycle it).

There is none. The required debug registers are only writeable from SWD, but not from the MCU core.

The only other way to disable the debug mode is to *completely* remove power after programming (via SWD) or debugging the chip.

EDIT: When the JLink debugger is still connected, the debug mode can be turned off with the jlink commander using the command "writeDP 1 0".

[Israel]

Thank you, I was afraid of this, We might need to implement a way to shut our power supply for a moment in the event we detect high power consumption. However this requires adding cost to the BOM, and it also needs question #1 to be answered.

[Turbo J]

One somewhat "interesting" way to detect this is that code continues to run after trying to go into System OFF mode. Execution stops when not in debug mode (and the chip needs pin wakeup that causes reset).

The JLINK command won't require additional hardware when you already have SWD.

[Nguyen Hoan Hoang]

Looks like intermittently your firmware got stuck in a while loop.  Look to see if you are not stuck in the i2c loop waiting for an event for example. 

[Israel]

I was looking into this too. But i am certain this is not the issue.
We have a "devlog" so we save to the data flash what the processor is doing, things such as button press or changes in power modes. The devlog indicates that the device went to "low battery warning" and then to" low battery shutdown" which is the nrf52 SYSTEM_OFF mode. So the program was running as usual, any I2C or SPI block would not allow to communicate with sensors or flash device. which in case we also log into flash any sensor communication error.