• State Not Answered
  • Replies 9 replies
  • Subscribers 25 subscribers
  • Views 492 views
  • Users 0 members are here
Attachments (4) Download All
Nordic Case Info
  • Case ID: 284956
Options

nrf5340DK debugger restarts, port disconnected

user113954

nrfjprog restarts nrf5340DK debugger

We are running a container environment in Ubuntu 20.04 on WSL2 and the USB ports are frwarded using usbipd

When trying to flash (or just reset) the nrf5340DK after connecting and disconnecting a terminal emulator program
the debugger chip seems to be restarting and the port is lost to the container.

This means we have to connect the ports again and restart the container, making it impossible to run automatic tests for instance

Steps to recreate:
1. Build the zephyr/samples/hello_world sample for nrf5340dk_nrf5340_cpuapp
2. flash the board with nrfjprog
3. Open a terminal emulator program (putty and picocom tested)
4. Reset the board to se the printout
5. Exit the terminal emulator program
6. Try to flash: the following error occurs:

ERROR: Unable to connect to a debugger.
ERROR: [SeggerBackend] - JLinkARM.dll Open returned error 'Cannot connect to J-Link.'
ERROR: [SeggerBackend] - JLinkARM.dll Open returned error 'Failed to open DLL'
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.

The we need to connect the port again in WSL and the restart the container to get it working again.

The question is, why do we end up in this state after using the emulator and is it possible to flash without resetting the debugger?

See attached log files

Environment:
nrfjprog: 10.15.2
jLink: DLL version V7.62a, compiled Feb 23 2022 17:02:35
Firmware: J-Link OB-nRF5340-NordicSemi compiled Dec 3 2021 15:46:49

Hardware: PCA10095 2.0.0

Log from when it fails:

Log from when it works:

Parents
  • 0

    Hi,

     

    We are running a container environment in Ubuntu 20.04 on WSL2 and the USB ports are forwarded using usbipd

    This is a setup that is not tested from our side and known to be prone to connectivity errors like you're seeing. I am not saying that the issue cannot be with jlink/nrfjprog, especially since you are running the newer DK with a nRF5340 interface MCU, but we'll need to dig a bit deeper here to see where in the chain that the issue occurs.

    I am unfortunately not able to reproduce this, with either pca10095 v0.12.0 or v2.0.0, when running on a native OS.

    The we need to connect the port again in WSL and the restart the container to get it working again.

    Q1: Is this occurring every time at your end? Or is it like 1 out of 10 runs that fail?

    Q2: does "dmesg" give any indication on what happened?

    Q3: Do other DK's also behave like this, or is this specific to the nRF5340-DK v2.0.0 ?

     

    nrfjprog: 10.15.2
    jLink: DLL version V7.62a, compiled Feb 23 2022 17:02:35
    Firmware: J-Link OB-nRF5340-NordicSemi compiled Dec 3 2021 15:46:49

    Q4: Have you tried using the bundled jlink versions in nrf command line tools (where nrfjprog is also found)?

     

    Kind regards,

    Håkon

Reply
  • 0

    Hi,

     

    We are running a container environment in Ubuntu 20.04 on WSL2 and the USB ports are forwarded using usbipd

    This is a setup that is not tested from our side and known to be prone to connectivity errors like you're seeing. I am not saying that the issue cannot be with jlink/nrfjprog, especially since you are running the newer DK with a nRF5340 interface MCU, but we'll need to dig a bit deeper here to see where in the chain that the issue occurs.

    I am unfortunately not able to reproduce this, with either pca10095 v0.12.0 or v2.0.0, when running on a native OS.

    The we need to connect the port again in WSL and the restart the container to get it working again.

    Q1: Is this occurring every time at your end? Or is it like 1 out of 10 runs that fail?

    Q2: does "dmesg" give any indication on what happened?

    Q3: Do other DK's also behave like this, or is this specific to the nRF5340-DK v2.0.0 ?

     

    nrfjprog: 10.15.2
    jLink: DLL version V7.62a, compiled Feb 23 2022 17:02:35
    Firmware: J-Link OB-nRF5340-NordicSemi compiled Dec 3 2021 15:46:49

    Q4: Have you tried using the bundled jlink versions in nrf command line tools (where nrfjprog is also found)?

     

    Kind regards,

    Håkon

Children
Related
Terms of service