• State Verified Answer
  • Replies 13 replies
  • Subscribers 75 subscribers
  • Views 3280 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 310557
Options

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.

  • 0 in reply to Rahav

    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. 

  • +1 in reply to Vidar Berg

    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.

  • 0 in reply to Rahav

    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 

Related
Terms of service