Resetting DIF to reduce interface current on nRF52

samsonc gravatar image

asked 2017-11-14 06:28:36 +0100

Hi, As has been mentioned many times, the DIF on both the nRF51 and nRF52 consumes quite a bit of current. In the past, on the nRF51, I've relied on power cycling both chipsets to reset the DIF, as I could get no debugger command to ever do this correctly.

I was hoping that this behavior would be corrected on the nRF52. I'm currently designing an application where the entirety of the device (battery, etc.) is fully encapsulated for a one-time-use application. Only a SWD interface (including !RESET) for reprogramming and testing in application is exposed. It's also used as a backup interface to read out some stored readings should the internal battery lose power.

Now, if the SWD interface ever accidentally gets enabled (I believe this was possible depending on noise on the nRF51), or if debug mode needs to be entered to read out stored readings, the chip will get stuck on the DIF.

Is there any known way to reset the DIF to reduce power consumption after a debug session through the interface or in software without a power cycle?

I have tried many recommendations on the forum to no avail. This includes a pin reset (both using a J-link and by manually shorting the reset pin). I've also verified that PSELRESET is configured appropriately. In fact, I can see the current consumption fall from ~3mA down to ~800uA for maybe half a second after RESET is held low, indicating that it is configured appropriately. After that, it just jumps to the normal current with DIF on.

All of the other components on the board have been accounted for - after power-on, without any DIF usage, the entirety of the board consumes 9uA, most of which comes from a separate component. The nRF52 consumes about ~1uA.

Any solutions? Perhaps there's some debugger command or internal DIF register that needs to be written? Or will I simply need to design hardware to power cycle the nRF52?

edit retag flag offensive close delete report spam

1 answer

Sort by » oldest newest most voted
Stian gravatar image

answered 2017-11-14 16:14:53 +0100

updated 2017-11-23 13:52:33 +0100

Hi, you can try to write to the DIF directly using JLinkExe and reset it.

Run Jlink.exe (JlinkExe in linux), do not connect to the chip, just make sure that the correct JLink is selected based on the serialnumber. Write this:

SWDWriteDP 1 0x04000000

That should reset the DIF, and current consumption should go down to normal.


I've noticed that this workaround does not work with JLink version 6.16 and higher in combination with the nRF52 DK onboard JLink (FW version 24.jul.17). It is still working with my JLink Lite programmer.

So if people reading this post can't get it to work try to install JLink 6.14a.


edit flag offensive delete publish link more


THANK YOU! This works perfectly. I've been looking for this information for quite a while. I'm guessing it may work with the nRF51 as well, which would be useful for some of my other prototypes.

Perhaps this should be integrated into nrfjprog, the standard gcc makefiles, or debug configuration? I can't think of a reason for why you wouldn't want to do this all the time after you're done flashing or debugging (I have seen the high current even while only flashing the device)

samsonc ( 2017-11-15 03:08:40 +0100 )editconvert to answer

This should be handled by the JLink automatically. Are you using read back protection? I've only been able to reproduce the issue when read back protection is activated, since you can't do a soft reset. Any info would be helpful so we can track down the cause of this. Can you please post debugger type/version, JLink dll version, JLink FW version, nrfjprog version etc.?

Stian ( 2017-11-15 08:38:19 +0100 )editconvert to answer

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

Question Tools

1 follower


Asked: 2017-11-14 06:28:36 +0100

Seen: 99 times

Last updated: nov. 23 '17