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

[Stian Røed Hafskjold]

1. The chip goes to debug state whenever the debuger is used. It is the debugger that puts the chip to debug state before writing to registers etc., for example when you want to enable RBP.

2. Debug mode is entered by writing specific commands through the SWD lines and it should therefore never enter debug mode unless you have a debugger connected and purposely enter debug mode.

Did you get the current draw down after connecting the reset pin to the debugger? I'm actually having problems here too when I tested it now, so it might be an issue with nrfjprog. I will keep you updated with what I find out.