read back protection puts tag to high current consumption

[Sal]

Hi, I am seeing an issue where after enabling read back protection (rbp) on NRF52 and using sdk 12.1 the tag goes to state where it drains a lot of current.

command used: nrfjprog -f NRF52 --rbp ALL

I have used power profiler to check the behavior, current drain jumps to about ~1.5 mA, from ~120 uA. Since nrfjprog commands are disabled after rbp, issuing a reset command (nrfjprog -f NRF52 --reset) would not help the issue, rather increases the current consumption even higher to about ~3.5 mA (although I see an error message indicating recover command should be used to talk to the chip again, but still the command seems to succeed the first time around and increase current drain even more):

$ nrfjprog -f NRF52 --reset ERROR: The operation attempted is unavailable due to readback protection in ERROR: your device. Please use --recover to unlock the device.

The only way to recover is via a battery pull (pinreset, or debugreset commands also do not seem to fix the issue as the current drain stays high).

Can you please help explain why (and also under what conditions) the chip goes to this state (probably "debug state"?) and how can I recover without a battery pull. I would need to have the rbp enabled and it seems using rbp is only one way the chip could get into this high current drain mode.

**Please help explain other possible conditions that could lead to this high current drain mode.

Thanks.

[Stian Røed Hafskjold]

Yes, the chip enters debug mode, and needs to be reset. You can reset by using a pin reset: infocenter.nordicsemi.com/.../power.html. The PSELRESET registers need to be set, and the p21 pin must be routed out to the debugger. You can do a pin reset with nrfjprog --pinreset

[Sal]

Thanks for your reply. I have already tried pinreset, and debugreset commands also do not seem to fix the issue as the current drain stays high.

$ nrfjprog -v nrfjprog version: 9.3.1 JLinkARM.dll version: 6.18a

The nrfjprog command also seems to succeed but the current drain is still high: $ nrfjprog -f NRF52 --pinreset Applying pin reset.

[Sal]

Hi Stian, Could you please help with the questions above. I am not sure why the pinreset command would not work. Is it possible that my revision of the nrf52 is old and falls under this side effect noted in nrfjprog: Side effects: After an --rbp operation is performed, the available operations are reduced. For nRF51 devices, and if argument option ALL is used, --pinreset will not work on certain older devices.

[Bjørn Kvaale]

Hi Sal. Have you looked at this DevZone case?

[Sal]

Hi Bjørn, Thanks for your reply. I have run more tests and applying --pinreset even on unlocked device (no --rbp) would not seem to reset the chip, as I do not see any indication of reset on power profiler.

I am not quite sure what is the difference between --reset and --pinreset commands. But I guess based on this post (devzone.nordicsemi.com/.../) it is required to have an extra wire connecting nRESET (pin 10) on the debugger chip to the RESET (pin 21) on nRF52 chip (although it is not suggested on the question thread).

Currently I have RESET pin on the nRF52 connected to a push button to wake up the device when in sleep.

Would you also please help me undrestand what --rbp command does? I see on the power profiler that after applying the command, it goes to "sleep" (i.e.: no advertising) and current drain spikes to around 3.40 mA (much more than typical ~2uA for sleep mode). Only way to recover now is to battery pull.

The other interesting observation I have is when I recover the chip (or --eraseall) I also see very high current drain. Is this expected? Or does it indicates a possible mistake on my hw design? Please let me know if you would like to review my schematic to double check.

Thanks in advanced!