Cannot connect to J-Link

[Rahav]

I am evaluating nRF52840 DK in the following development environment:

• Contiki-NG ver 4.7 running in the standard Contiki container. Per Contiki, the container has all the required development tools for Nordic devices.

After connecting the DK it is present as two devices: ttyACM0 and ttyACM1. I further validated that Contiki recognizes it and can connect:

make TARGET=nrf52840 motelist-all
python ../../tools/motelist/motelist.py
Port          Serial        VID     PID     Product  Vendor
------------  ------------  ------  ------  -------  ------
/dev/ttyACM0  0x1050232358  0x1366  0x1051  J-Link   SEGGER
/dev/ttyACM1  0x1050232358  0x1366  0x1051  J-Link   SEGGER

However, when programming the DK, I get the following error. Also attached is the requested log.log file.

I tried with different cables and the two device ports listed above to no avail.

make TARGET=nrf52840 PORT=/dev/ttyACM0 hello-world.upload
nrfjprog -f nrf52  --sectorerase --program build/nrf52840/dk/hello-world.hex
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.
../../arch/cpu/nrf52840/Makefile.nrf52840:127: recipe for target 'hello-world.upload' failed
make: *** [hello-world.upload] Error 33

Fullscreen 64157.log.log Download

[2023-Jun-29 19:29:05] [ info] --------------------------------------------------------------------------------
[2023-Jun-29 19:29:05] [ info] nrfjprog -f nrf52 --sectorerase --program build/nrf52840/dk/hello-world.hex --log 
[2023-Jun-29 19:29:05] [ info] nrfjprog version 10.12.1 
[2023-Jun-29 19:29:05] [ info] --------------------------------------------------------------------------------
[2023-Jun-29 19:29:05] [debug] [ nRF0x0] - open_dll
[2023-Jun-29 19:29:05] [ info] [ nRF0x0] - Load library at /opt/nrfjprog/libjlinkarm_nrf52_nrfjprogdll.so.
[2023-Jun-29 19:29:05] [ info] [ nRF0x0] - Library loaded, loading member functions.
[2023-Jun-29 19:29:05] [ info] [ nRF0x0] - Member functions succesfully loaded.
[2023-Jun-29 19:29:05] [ info] [Backend] - Logger callback at 0x565740e0 registered in Segger backend logger.
[2023-Jun-29 19:29:05] [ info] [  JLink] - [Info    ] [JLink     ] Logger callback at 0x565740e0 registered in JLink logger.
[2023-Jun-29 19:29:05] [debug] [nRF520x0] - open
[2023-Jun-29 19:29:05] [debug] [Backend] - open_dll
[2023-Jun-29 19:29:05] [ info] [Backend] - No J-Link DLL path was provided. Attempting to auto detect.
[2023-Jun-29 19:29:05] [ info] [Backend] - Load library at /opt/SEGGER/JLink/libjlinkarm_x86.so.
[2023-Jun-29 19:29:05] [ info] [Backend] - Library loaded, loading member functions.
[2023-Jun-29 19:29:05] [ info] [Backend] - Member functions succesfully loaded.
[2023-Jun-29 19:29:05] [debug] [Backend] - dll_version
[2023-Jun-29 19:29:05] [ info] [Backend] - Segger dll version 6.88.a loaded.
[2023-Jun-29 19:29:05] [debug] [ nRF0x0] - enum_emu_snr
[2023-Jun-29 19:29:05] [debug] [nRF520x0] - enum_emu_snr
[2023-Jun-29 19:29:05] [debug] [Backend] - is_connected_to_emu
[2023-Jun-29 19:29:05] [debug] [Backend] - enum_emu_snr
[2023-Jun-29 19:29:05] [debug] [Backend] - ---just_enum_emu_snr
[2023-Jun-29 19:29:05] [debug] [Backend] - ---just_get_num_emus
[2023-Jun-29 19:29:06] [debug] [Backend] - is_connected_to_emu
[2023-Jun-29 19:29:06] [debug] [ nRF0x0] - connect_to_emu_with_snr
[2023-Jun-29 19:29:06] [debug] [nRF520x0] - connect_to_emu_with_snr
[2023-Jun-29 19:29:06] [debug] [Backend] - is_connected_to_emu
[2023-Jun-29 19:29:06] [debug] [Backend] - connect_to_emu_with_snr
[2023-Jun-29 19:29:06] [debug] [Backend] - is_connected_to_emu
[2023-Jun-29 19:29:06] [debug] [Backend] - ---just_enum_emu_snr
[2023-Jun-29 19:29:06] [debug] [Backend] - ---just_get_num_emus
[2023-Jun-29 19:29:08] [debug] [Backend] - ---just_connect_to_emu_with_snr
[2023-Jun-29 19:29:08] [debug] [Backend] - ---just_connect_to_emu_without_snr
[2023-Jun-29 19:29:08] [ info] [Backend] - Segger logging enabled.
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ]    ***** Error: 
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] Cannot connect to J-Link.
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] - 12.528ms returns "Cannot connect to J-Link."  
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] JLINK_HasError()  
[2023-Jun-29 19:29:08] [ info] [Backend] - JLinkARM.dll Open returned error 'Cannot connect to J-Link.'
[2023-Jun-29 19:29:08] [debug] [Backend] - is_connected_to_emu
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] JLINK_IsOpen()  
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] - 0.009ms returns 0x00  
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] JLINK_HasError()  
[2023-Jun-29 19:29:08] [debug] [ nRF0x0] - close_dll
[2023-Jun-29 19:29:08] [debug] [nRF520x0] - close
[2023-Jun-29 19:29:08] [debug] [Backend] - is_connected_to_emu
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] JLINK_IsOpen()  
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] - 0.009ms returns 0x00  
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] JLINK_HasError()  
[2023-Jun-29 19:29:08] [debug] [Backend] - close
[2023-Jun-29 19:29:08] [debug] [Backend] - disconnect_from_emu
[2023-Jun-29 19:29:08] [debug] [Backend] - is_connected_to_emu
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] JLINK_IsOpen()  
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] - 0.010ms returns 0x00  
[2023-Jun-29 19:29:08] [ info] [  JLink] - [Info    ] [JLink     ] JLINK_HasError()  
[2023-Jun-29 19:29:08] [debug] [Backend] - Segger Backend closed.
[2023-Jun-29 19:29:08] [debug] [nRF520x0] - nRF family DLL closed

Thank you for your answer.

[Vidar Berg]

Hello,

The nrfjprog log indicates that communication is failing between the PC and the debugger, rather than between the debugger and the nRF, which is a more common issue. I'm not familiar with Contiki, but I wonder if this could be related to the container setup and permissions. I can see that the COM ports are being enumerated correctly (ttyACMx), but the programming is not being done through this interface.

To help narrow down the problem, could you try running nrfjprog outside the container or on another PC to see if you encounter the same error? You can run 'nrfjprog -e' as a test. This command is to erase the flash on the chip.

Best regards,

Vidar

[Rahav]

Thank you, Vidar. Here are the results of running inside the Contiki Docker container:

user@3ac6208fa39d:~/contiki-ng$ nrfjprog -e
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.
user@3ac6208fa39d:~/contiki-ng$ nrfjprog -e --log

Attached is the log.

I believe the authors of Nordic SoC for Contiki are Alex Stanoev and Wojciech Bober, both from Nordic. Here is the link to Contiki nRF52840 documentation.

While I wait for your answer, I will install Contiki on another VM.

[Vidar Berg]

1. You need to select one of the x64 downloads. However, the choice of installer depends on the Linux distribution you are using. If you have a Debian-based distribution, you can use the *.deb package.

2. The only additional package that should be installed is the J-link driver. 

Installing the nRF Command Line Tools

[Rahav]

I installed nRF command line tools on the Linux VM, which runs on the same machine. Running the command you requested leads to the following:

nrfjprog -e
[error] [ Client] - Encountered error -90: Command read_device_info executed for 17 milliseconds with result -90
[error] [ Worker] - Access protection is enabled, can't read device version.
[error] [ Client] - Encountered error -90: Command read_memory_descriptors executed for 23 milliseconds with result -90
[error] [ Worker] - Can't read memory descriptors, ap-protection is enabled.
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

What is the next step?

[Rahav]

Similar results when running directly from the Mac computer:

nrfjprog -e

[error] [ Client] - Encountered error -90: Command read_device_info executed for 3 milliseconds with result -90

[error] [ Client] - Encountered error -90: Command read_memory_descriptors executed for 3 milliseconds with result -90

[error] [ Worker] - Access protection is enabled, can't read device version.

[error] [ Worker] - Can't read memory descriptors, ap-protection is enabled.

ERROR: The operation attempted is unavailable due to readback protection in

ERROR: your device. Please use --recover to unlock the device.

NOTE: For additional output, try running again with logging enabled (--log).

NOTE: Any generated log error messages will be displayed.

[Vidar Berg]

nrfjprog is able to communicate with the nRF chip now. As the error message suggests, you can run 'nrfjprog --recover' to turn off readback protection on the chip. 

[Rahav]

What is readback protection? Who set it up in the first place? Will I need to do that with all the devices I bought? Is it discussed in the user guide?

[Vidar Berg]

Readback or access port protection is a feature mainly used to prevent the FW code to be extracted from the device. It is enabled by default in the latest build code. You can read more about how it works in the Access port protection section of the product specification.

Anyway, what this test shows is that nrfjprog works fine when invoked outside the Contiki container. My guess is that it is an issue related to permissions, but as I'm not familiar with this setup, I'm afraid I can't help you troubleshoot this further. I recommend you raise this issue on github. 

[Rahav]

I still cannot properly evaluate the nRF52840, but I believe that I have an answer to what was causing the problem.

I ordered new USB-C to USB micro-B 2.0 cables, from multiple companies. The ones I tested so far work and I can program the nRF52840.

There is another problem now. It seems that after each programming of the nRF52840, it becomes readback enabled. The problem then persist because it often takes multiple nrfjprog --recover to disable it.

If automatic readback locking and unlocking is what Nordic desired for this product, then it should be clearly communicated in the getting started. Otherwise, after one programming the boards becomes unusable. With that in mind, I have the following questions:

1. How are we suppose to disable readback protection on a regular basis before each re-programming?
2. What is the proper way to do it?

Lastly, I hope that someone at Nordic takes a look at whether a better error code can be issued when a cable does not allow programming.

[Vidar Berg]

OK, so it was the USB cable that was the culprit. Some cables are for charging only, but since the COM ports were enumerated, there had to be some data communication taking place between your devices in your case. I don't think there is a good way to reliably detect issues like these in software.

Rahav said:

There is another problem now. It seems that after each programming of the nRF52840, it becomes readback enabled. The problem then persist because it often takes multiple nrfjprog --recover to disable it.

The readback protection should be disabled on boot by the startup files, but it appears that Contiki is using an older SDK version (nRF5 SDK v16.0.0), which is not compatible with the latest silicon revision (functional changes in silicon rev.3).

Rahav said:

How are we suppose to disable readback protection on a regular basis before each re-programming?

When using the startup files for the new build code, you should only need to unlock the device before the initial programming. It should then remain unlocked during subsequent re-programming of the device.

We include relevant documentation handling access port protection in our SDK documentation here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.0/nrf/app_dev/ap_protect/index.html