JLink hangs after reset from nrfjprog v10.10+

[Rodrigo Brochado]

Hi,

I was using JLink v7.50a with nrfjprog 10.9.0 and debug were working fine on Ubuntu 20.10 using SWD pins and JLink RTT. After changing to Ubuntu 21.10 and installing up to date version of both programs, my JLinkRTTViewer was hanging (no more logs) after executing a nrfjprog -r or nrfjprog -p.

I then thought it was a problem with JLink auto-detection feature, but I've checked that a reset with the reset button of our boards didn't cause the JLink logs to hang.

So it seems that nrfjprog is messing with something on SWD protocol (?) and the Inteface MCU can't get back to the RTT logs?

I've made some tests with other versions nrfjprog and JLink. Tests made on Ubuntu 21.10 (kernel 5.13.0-23-generic), with our nrf52840 custom board and using Nina B302-EVK (the interface MCU should work the same as nRF52840-DK, right?). Our board has zephyr vanilla FW inside with RTT enabled. To get the logs we use the following:

JLinkExe -device NRF52840_XXAA -if SWD -speed 20000 -autoconnect 1

# on other terminal:

JLinkRTTClient

The problem was the same using JLinkRTTLogger or JLinkRTTViewer.

Results for different versions:

10.9      with 7.50a -> ok
10.10    with 7.50a -> not ok
10.12    with 7.50a -> not ok
10.13    with 7.50a (default) -> not ok
10.15.1 with 7.58b (default) -> not ok
10.15.1 with 7.60b -> not ok
10.15.1 with 7.50a -> not ok

 

Could you reproduce this problem at your sides?

Thanks!

Best,

[Vidar Berg]

Hi,

Have you tried to use --debugreset instead? nrfjprog is actually supposed to make the chip exit debug interface mode after a --reset to avoid excessive power consumption after programming (base current in debug mode is ̃around 3 mA). There was however a bug in nrfjprog 10.9 that prevented it from powering down the debug interface, so that would explain why RTT kept working after reset earlier.

Best regards,

Vidar

[Rodrigo Brochado]

Thanks for the answer, Vidar.

I've tested with --debugreset now and also with --hardreset (although this one should not work based on your info on power precautions) on v10.15.1 with JLink 7.50a, 7.58b and 7.60b, and it didn't worked either. 

[Rodrigo Brochado]

Nice!
I can confirm that resetting in jlink commander works.

Thank you!

[Rodrigo Brochado]

Hello

Any updates on this?

I don't know if I passed the wrong information here. I meant that the commands "r" and "g" on the jlink commander worked, BUT I still have the problem described above.

I tested nrfjprog 10.16 today, because the latest nrfconnect 3.12.0 is compatible to its Jlink version, but the problem persist on nrfjprog 10.16.

Thank you.

[Vidar Berg]

Hello,

No, your issue description was clear, and I did report it internally too. It just seems like the nrfjprog team has not had a chance to follow up on it yet. I will send them a reminder.

[lvh831]

I have the same problem. Either I have to run "r" or "con" in J-Link. I ran JLinkExe with -AutoConnect 1 but that didn't help. Is the problem is on JLinkExe or on nrjprog?

[Vidar Berg]

nrfjprog will force the chip out of Debug Interface mode when you perform a reset, which is typically what you want after loading a new FW image. But this will also kill any active RTT sessions. If the chip had remained in debug mode it would have increased the overall power consumption of your device.

The workaround is to keep the debug session active by resetting the device from a Jlink commander session, or re-establish the debugger connection after a nrfjprog reset.