read back protection puts tag to high current consumption

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Wed, 29 Nov 2017 15:54:52 GMT

You can connect it like this if you only want to measure current going in to the nRF5 chip:

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Wed, 29 Nov 2017 14:01:35 GMT

To answer your question 3 above: You need to connect the ribbon cable to the debug IN port on the nRF52 DK. In the picture it is connected to Debug out. Now it should be directed automatically.

To answer your question 4 above: If you measure current going in to the External supply header of the nRF52 DK, you also measure everything on the DK including SEGGER debug chip.

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Wed, 29 Nov 2017 13:56:38 GMT

Hi, the reason why the workaround I posted does not work seems to be related to JLink version and type of JLink. If you are using the DK to flash, the workaround does not work in JLink software version 6.16 or newer. Please revert the software version to 6.14a. You can download this from JLink homepage.

You are right that pinreset itself causes a high current consumption on the newer JLink SW version. So the only way that I'm able to get the power down while RBP is active is by using the SWDWrite workaround, nothing else works.

So please try again with JLink SW version 6.14a

RE: read back protection puts tag to high current consumption

Sal — Mon, 27 Nov 2017 23:12:37 GMT

Stian, any updates?

RE: read back protection puts tag to high current consumption

Sal — Mon, 23 Oct 2017 21:33:37 GMT

I am using a Ubuntu vm to program chip and windows 7 to power profile (The commands are issued from Ubuntu therefore linux: JLinkExe).

Tried your suggestion on my custom board, still seeing the same issue (does not exit debug mode). Here is the logs and revision of jlink/nrfjprog:

$ nrfjprog -v
nrfjprog version: 9.7.1
JLinkARM.dll version: 6.20e

$ JLinkExe
SEGGER J-Link Commander V6.20e (Compiled Oct  6 2017 17:06:37)
DLL version V6.20e, compiled Oct  6 2017 17:06:32


Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 24 2017 17:30:12
Hardware version: V1.00
S/N: 681792490
VTref = 3.300V


Type "connect" to establish a target connection, '?' for help
J-Link>SWDSelect
Select SWD by sending SWD switching sequence.
Found SWD-DP with ID 0x2BA01477
J-Link>SWDWriteDP 1 0x04000000
Write DP register 1 = 0x04000000
J-Link>

I also have a board with pin reset connection you suggested earlier. Trying the same command on it would also not exit debug mode. Also tried just the pinreset command and it also seems to put the tag in the high current mode (very strange!). For your reference here are the command sequence:

Program tag
check the current drain and issue a reset to make sure: nrfjprog --reset
run pinreset and monitor the current nrfjprog --pinreset
the current drain jumps to around ~3 mA. This is even without rbp enabled.

I am currently trying to use the same setup as yours to eliminate any hw issues on my custom board. Attached please find the setup I am using to measure the current and issue commands (rbp/reset/etc.) at the same time (screenshot attached above).

The nrf52 dev kit is running the below hex file (top right dev kit). nRF5_SDK_12.1.0_0d23e2a\examples\ble_peripheral\ble_app_beacon\hex\ble_app_beacon_pca10040_s132.hex
It is powered via the devkit(nrf51) and ppk setup (buttom dev kit -- connected to windows 7 host).
A third dev kit (nrf51 -- top left -- connected to Ubuntu vm) is used to issue commands via the ribbon cable as shown on the screenshot. However, the commands are not directed to the NRF52 chip. Instead they are directed to the nrf51 kit (top left dev kit). (Please let me know if there is a jumper setup that would direct the command to the nrf52 kit. If the setup is not correct please share your setup).
On the ppk ui I see the average current about ~550uA (which application you are using that would give 2uA?)
Please note that this is the same setup I am using when using my custom board to measure current (here in the screenshot it is only replaced with NRF52 kit -- top right board).

Thanks.

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Thu, 05 Oct 2017 07:24:57 GMT

I tried now with the PPK connected with a separate debugger, powering the DUT on the "External DUT" port. Based on your previous comments I believe this is equivalent to your setup.

What I did:

Idle current is 2 µA, reading from PPK
nrfjprog --reset
Current is still 2 µA
nrfjprog --rbp ALL
Current is now 3 mA
nrfjprog --pinreset
Current is still 3 mA, so I'm able to confirm the behaviour on my side.
Open "JLink Commander" in windows (or JLinkExe in linux)
SWDSelect
SWDWriteDP 1 0x04000000
Current goes down to 2 µA IDLE again.

I tried first with JLink v5.10d. But then JLink Commander would not send the SWD commands. Then I tried with v6.16b, and it worked. So maybe it is something wrong with the version you are using. These are my versions:

nrfjprog version: 9.2.0
JLinkARM.dll version: 6.16b

Are you using linux or windows?

RE: read back protection puts tag to high current consumption

Sal — Tue, 03 Oct 2017 17:43:22 GMT

Hi Stian,

I added a connection from the reset pin (p0.21 on schematics) to the pin 10 of the J1. I can see that the "nrfjprog -f NRF52 --pinreset" command now works and it initiates a reset when chip is locked (--rbp). However the current stays high still (~3.30 mA, after enabling the read back protection).

Were you able to confirm the behavior on your side?

I do not think the command is sent to the power profiler kit. Using voltmeter on the P0.19 (pin22) would show the voltage (around 2.71v) also measuring the current on the same pin would always show a constant value of around 190 uA regardless of debug/normal mode.

Thanks.

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Wed, 27 Sep 2017 09:21:28 GMT

The command still works without the pin reset.

I see that you are also using a Power Profiler Kit. Can it be that the SWD commands are sent to the PPK instead? What if you use a multimeter to monitor the current on P22 so that only the target is connected to your computer?

RE: read back protection puts tag to high current consumption

Sal — Wed, 27 Sep 2017 00:42:33 GMT

I tried the new steps. Unfortunately it still does not help with the current drain. Stays very high. Please note that the pin reset will not work on my target as I am missing a connection (can not modify as the target as it is a production unit.) Would the command work still without this connection?

Do you see the same behavior on your setup?

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Mon, 25 Sep 2017 09:50:15 GMT

I will try your setup with the PPK and different versions of JLink and report back. But first, just to answer your question 1) If you use nrfjprog to enable RBP, you also enable debug mode. The JLink (nrfjprog) needs to write to a register in order to enable this mode, so then debug mode is also enabled.

You are right that the chip is locked after RBP and you are not able to do a soft reset. But, if you use JLinkExe without issuing the "connect" command, you can write commands over SWD directly to the debug interface and access registers that are not locked after RBP. So execute the following sequence without connecting to the chip. Just write SWDSelect etc. right after opening JLinkExe:

JLinkExe
SWDSelect
SWDWriteDP 1 0x04000000
exit

This will reset the debug interface so that the current goes down. Then you can do a pin reset afterwards to reset the chip.

RE: read back protection puts tag to high current consumption

Sal — Fri, 22 Sep 2017 18:38:23 GMT

Yes, for debugging I use JLinkExe and connect to target via SWD interface and default speed (4000 kHz), and on the power prfiler I see the current drain goes high (~4ma) this is expected. Also on terminating the JLinkExe or simply disconnecting the ribbon cable I am able to exit and see the current drain goes back to normal.

However, for programming the chip and enabling the RBP I use nrfjprog tool, this should not enable debugging. Please confirm.

Unfortunately I am not able to modify the target to test the setup.

There seems to be an issue with different combinations of nrfjprog and Jlink that would not issue a soft reset to exit debug mode. I think this revision works okay:

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

After programming the chip via commands below the reset work okay and current drain goes down:

$ nrfjprog -f NRF52 --program ./merged.hex --verify --chiperase --reset

**But the --reset doesn't seem to work on this older rev combination for example: $ nrfjprog -v nrfjprog version: 8.5.0 JLinkARM.dll version: 6.12a

(this is maybe the issue you are experiencing)

**3) Please try these commands on your setup (you should see similar issue as I am experiencing):

-program the kit and monitor with ppk at the same time (use a different debug kit for this as there seems to be an issue where the same debug kit can not be used to program and run ppk):

$ nrfjprog -f NRF52 --program ./merged.hex --verify --chiperase --reset

-enable rbp: $ nrfjprog -f NRF52 --rbp ALL

(the chip should go to "sleep" with high current drain)

-try the same command above again or force a "reset":

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

(You should see higher current drain but wakes up the chip)

Now launching the debugger (JLinkExe) and trying the command you mentioned as below would not still work as the chip is locked. The chip would go back to sleep with even higher current drain. Logs below:

$ JLinkExe SEGGER J-Link Commander V6.18a (Compiled Aug 11 2017 17:53:58) DLL version V6.18a, compiled Aug 11 2017 17:53:53

Connecting to J-Link via USB...O.K. Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 24 2017 17:30:12 Hardware version: V1.00 S/N: 681691590 VTref = 3.300V

Type "connect" to establish a target connection, '?' for help J-Link>connect Please specify device / core. : NRF52832_XXAA Type '?' for selection dialog Device> Please specify target interface: J) JTAG (Default) S) SWD TIF>S Specify target interface speed [kHz]. : 4000 kHz Speed> Device "NRF52832_XXAA" selected.

Connecting to target via SWD Found SW-DP with ID 0x2BA01477 CTRL-AP indicates that the device is secured. For debugger connection the device needs to be unsecured. Note: Unsecuring will trigger a mass erase of the internal flash. Device will be unsecured now. Found SW-DP with ID 0x2BA01477 Scanning AP map to find all available APs AP[2]: Stopped AP scan as end of AP map has been reached AP[0]: AHB-AP (IDR: 0x24770011) AP[1]: JTAG-AP (IDR: 0x02880000) Iterating through AP map to find AHB-AP to use AP[0]: Core found AP[0]: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x410FC241. Implementer code: 0x41 (ARM) Found Cortex-M4 r0p1, Little endian. FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl[0] @ E00FF000 ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM Cortex-M4 identified. J-Link>SWDSelect Select SWD by sending SWD switching sequence. Found SWD-DP with ID 0x2BA01477 J-Link>SWDWriteDP 1 0x04000000 Write DP register 1 = 0x04000000 J-Link>exit

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Thu, 21 Sep 2017 14:42:09 GMT

Seems like there's an issue with the jlink dll or nrfjprog so that the debug interface is never reset when you exit debug mode after RBP is activated. Not sure exactly what causes this, could be an issue with some versions of jlink dll only. I will investigate further. However, you can reset the debug interface manually through JLinkExe, and that should fix the issue.

Open JLink Commander (windows) or JLinkExe (Linux) and write the following:

SWDSelect
SWDWriteDP 1 0x04000000
exit

This should get the current consumption down to normal.

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Thu, 21 Sep 2017 11:24:46 GMT

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

RE: read back protection puts tag to high current consumption

Sal — Tue, 19 Sep 2017 16:56:50 GMT

Hi Stian,

Thank you for your response. Could you please help with my questions below:

Why the chip goes to debug state after enabling the rbp? (I can reliably reproduce)
Are there other possible conditions that would put the chip into debug state? My use case for the NRF52 is beacon 2 or 3 different frames on varying intervals. Also configuring them and save the state on flash. If the chip goes to debug mode I will not have any way of knowing other than premature battery drain in the field.

Thanks.

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Tue, 19 Sep 2017 08:49:18 GMT

Hi, I looked at your schematic and I think the problem is that you need to connect the reset pin on nRF52 (pin 21) to the debugger (pin 10 on J1 in your schematic).

RE: read back protection puts tag to high current consumption

Sal — Mon, 18 Sep 2017 20:46:28 GMT

Hi Stian, Bjørn, do you have any updates? Thanks.

RE: read back protection puts tag to high current consumption

Sal — Fri, 08 Sep 2017 23:31:57 GMT

Hey Bjørn, sorry for the late response. I will message you the file. Thanks!

RE: read back protection puts tag to high current consumption

Bjørn Kvaale — Thu, 07 Sep 2017 06:36:56 GMT

Hey Sal. The difference between --reset & --pinreset and the definition of the --rbp command can be found here. I think it would be easiest if I could take a look at your schematic to understand why the current drain is so high. Hope that helps a bit!

RE: read back protection puts tag to high current consumption

Sal — Tue, 05 Sep 2017 18:50:52 GMT

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!

RE: read back protection puts tag to high current consumption

Bjørn Kvaale — Tue, 05 Sep 2017 10:52:33 GMT

Hi Sal. Have you looked at this DevZone case?

RE: read back protection puts tag to high current consumption

Sal — Thu, 31 Aug 2017 20:23:07 GMT

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.

RE: read back protection puts tag to high current consumption

Sal — Tue, 29 Aug 2017 16:46:40 GMT

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.

RE: read back protection puts tag to high current consumption

Stian Røed Hafskjold — Tue, 29 Aug 2017 16:01:09 GMT

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