Cortex-debug with dev-container. How to connect to JLinkRemoteServer outside docker?

[andyinno]

Upon @haneefdm comment I am creating a new issue for this question.

I am trying to connect to my JLink adapter but vscode stops the debug as soon as I connect.

I am launching JLinkRemoteServerExe on host computer

I am using this configuration:

  {
            "type": "cortex-debug",
            "name": "Remote",
            "servertype": "jlink",
            "ipAddress": "192.168.1.87",
            "device": "ATSAM3A4C",
            "serverpath": "JLinkGDBServerCLExe",
            "request": "launch",
            "executable": "${workspaceRoot}/build/test_executable.elf",
            "runToMain": true,
            "svdFile": "${workspaceRoot}/.vscode/ATSAM3A4C.svd",
            "serverArgs": [
                "-rtos",
                "GDBServer/RTOSPlugin_FreeRTOS"
            ],
            "swoConfig": {
                "enabled": true,
                "cpuFrequency": 84000000,
                "swoFrequency": 7500000,
                "source": "probe",
                "decoders": [
                    {
                        "type": "console",
                        "label": "ITM0",
                        "port": 0,
                        "encoding": "ascii"
                    }
                ]
            }
        },

What I get on the vscode terminal is:

Connecting to J-Link...
J-Link is connected.
...
Checking target voltage...
Target voltage: 3.28 V

Therefore docker connects to host and host query the JLink device... but after some line (less than a second):

Waiting for GDB connection...SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...

My host is a ubuntu OS. I just want to have my own docker instance with all the tools already setup.

thank you in advance

If I try to connect from outside the docker instance (reopen folder on host) I can connect to the board with this setup.

As a sidenote:

@haneefdm you are right that I was polluting a different topic with this question, however your comment

You are doing something this tool was not designed for

Is something unexpected to me. Can you elaborate on this? I think that:

• Windows -> WSL -> Toolchain in Docker

is really similar to:

• Any Linux distro -> Docker -> Toolchain in Docker

We both want to be able to use standardized tools on different hosts and being able to code and debug our software

[haneefdm]

The whole process of how a gdb-server is launched, the ip-addresses involved, TCP port allocation never envisioned the gdb-server to be on another computer/environment other than the host itself.

This does include 'external' type servers where you control/launch the servers external to VSCode/Cortex-Debug. There you are fine doing whatever but may have limited functionality as such.

When we launch the server, however, we never expected the server to be running anywhere other than locally.

In your case, you may be having the local jlink server having trouble talking to a remove jlink server which is again an entirely different scenario. It may not even have anything to do with VSCode/Cortex-Debug either.

I would not have started a new task/project to do remote debugging (WSL/Docker/SSH) if it was already doing all of that.

[andyinno]

Thank you for your kind reply,

you wrote that you started a new task/project if it was already doing all of that.

Could be that you are only targetting WSL/Docker/SSH and this could be applicable also to other scenarios? There is something that could be tested?

I mean, all the dev-container thing is in my opinion a good strategy for developing software. Installing toolchains and path configurations are handled once in docker and deployed everywhere.

If debugging do not work, it is a no-go for dev-containers or for cortex-debug.

[haneefdm]

@andyinno Since you were seeking help from @TorBlackbeard I thought I would mention it here so they get notified.

you wrote that you started a new task/project if it was already doing all of that.

I said I would NOT have started a new task/project #467

Could be that you are only targetting WSL/Docker/SSH and this could be applicable also to other scenarios? There is something that could be tested?

Yes, that is why I am taking a step back and taking a look.

If debugging do not work, it is a no-go for dev-containers or for cortex-debug.

It takes time to do these things -- which is why I am asking for different opinions, use-cases. I would love to see it happen, but it doesn't make it happen. There is no army of developers here. Just me, part-time.

Since people have made some progress on their own, I am sure someone will step in and help you in your situation. Do post what worked for you.

[TorBlackbeard]

Just works for me ...

    "configurations": [
        {
            "name": "run/debug: jlink IP",
            "cwd": "${workspaceRoot}",
            "executable": "my.out",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "jlink",
            "serverpath": "JLinkGDBServerCLExe",
            "ipAddress": "192.168.1.47",
            "device": "STMxxxx",
            "svdFile": "stmxxxx.svd",
            "runToMain": true,
        },

Hints:

• be sure to run same version of jlink tools in container and docker

• make a firewall rule to allow jlinkremoteserver.exe to allow inbound connections
  (I'm lazy, I allowed TCP/UDP from all IPs/ports. When you get it working you can reduce scope.)

• try to do it without antivirus (McAfee is a notorious culprit)

• watch the JlinkRemote gui on the windows side. Is the 'line' that symbolises 'connection'

• • red all the time (you are not aiming at the right ip address)
• • flashes green for ~1 second:
    Ip is correct, but something is messed up. That can be everything from no Power on DUT, to IP/McAffee problems
• • Green for longer time (probably not, since you are posting problems)

• Can you ping the Windows host from the docker. (ping is misleading, because McAfee blanket allows this, and blocks real UDP/TCP connections.

• Can you connect something else via TCP from docker to a listening port on the windows box?

• I have this working on VPN and non-vpn. For me, I always use the IP listed as 'preferred' when doing ipconfig /all.
  To some surprise, I must use the ip 192.168.0.x adress, even when VPN is connected via ip 172.x.y.z.

  Let me know how it goes!

[TorBlackbeard]

Case: Working environment, but I close JLinkRemoteServer
Terminal tab:

SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected
SEGGER J-Link GDB Server V6.89b (beta) Command Line Version

JLinkARM.dll V6.89b (DLL compiled Dec  3 2020 15:52:13)

Command line: -singlerun -nogui -if swd -port 50000 -swoport 50001 -telnetport 50002 -device STM32L562CE -select ip=192.168.1.47
-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     50000
SWO raw output listening port: 50001
Terminal I/O port:             50002
Accept remote connection:      yes
Generate logfile:              off
Verify download:               off
Init regs on start:            off
Silent mode:                   off
Single run mode:               on
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         IP
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 STM32L562CE
Target interface:              SWD
Target interface speed:        4000kHz
Target endian:                 little

Connecting to J-Link...
Connecting to J-Link failed. Connected correctly?
GDBServer will be closed...
Shutting down...
Could not connect to J-Link.
Please check power, connection and settings.SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...

Tab: "Debug Console"

Please check TERMINAL tab (gdb-server) for output from JLinkGDBServerCLExe
Launching server: "JLinkGDBServerCLExe" "-singlerun" "-nogui" "-if" "swd" "-port" "50000" "-swoport" "50001" "-telnetport" "50002" "-device" "STM32L562CE" "-select" "ip=192.168.1.47"

[TorBlackbeard]

Case: Working environment, but I disconnect the debugger-cable to DUT (Jlink is still correctly connected)

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V10 compiled Aug  9 2021 10:30:48
Hardware: V10.00
S/N: 600001234
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage...
Target voltage: 3.62 V
Listening on TCP/IP port 50000
Connecting to target...
ERROR: Could not connect to target.
Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...
Shutting down...
Could not connect to target.

[TorBlackbeard]

Case: Successfull connection:
Tab: Debug Console

Please check TERMINAL tab (gdb-server) for output from JLinkGDBServerCLExe
Launching server: "JLinkGDBServerCLExe" "-singlerun" "-nogui" "-if" "swd" "-port" "50000" "-swoport" "50001" "-telnetport" "50002" "-device" "STM32L562CE" "-select" "ip=192.168.1.47"
Launching GDB: "arm-none-eabi-gdb" "-q" "--interpreter=mi2"

So interesting point is that it says "Launching GDB" - (probably after flashing is done, and it actually starts 'debugging'. But thats just imho.)

Terminal->gdb-server:

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V10 compiled Aug  9 2021 10:30:48
Hardware: V10.00
S/N: 600001020
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage...
Target voltage: 3.62 V
Listening on TCP/IP port 50000
Connecting to target...
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x080228CA (Data = 0x6A34E7DB)
etc 
etc
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x080228CA)
Received monitor command: reset
Resetting target
Downloading 500 bytes @ address 0x08000000
etc
etc

[TorBlackbeard]

You could also :
1)
try to start a real "JLink GDB Server" on the windows side and then use another vscode module, so it's not "servertype": "jlink" but probably "external".
I didn't try this. And if IP/firewalling is root cause, you are probably in for the same problems with that approach.

Try to use a RaspPI, and see if you can target that.
That goes for both JLinkRemoteServer and JLinkGDBServer.
(Not 100% sure what exist on the Arm build of JLink tools.)

[andyinno]

Thank you both @TorBlackbeard and @haneefdm

I already hit this issue before but completely forgot the solution.

Basically my configuration was really really similar to the one @TorBlackbeard posted.

What I was noticing was:

• green line in the external JLinkRemote
• internal Jlink not starting

Running the commands from the command line inside the container by hand the error message was really clear.

libncurses5 not installed in the docker environment.

Rebuilding the docker container with libncurses5 installed solved the issue.

Just for reference, it was already addressed here #266 .

@haneefdm: I said I would NOT have started a new task/project #467

Yes, I read all the comments there. I published my first post there for this reason: It seems to me that using JLink Windows/Linux or Linux/Linux is mostly the same at the moment. The reason, in my opinion, why devcontainers comes to hand is when you do not know which computer your next developer will work on, therefore provide a base container where the different tools are installed is really a plus.
I do not know the WSL2 subsystem would provide any difference but if possible to keep in mind other uses cases for devcontainers other than the expressed in the issue #467 would be really appreciated.

Thank you to both again
Andrea

[haneefdm]

Darn it. We are cursed by libncurses again. Why is it that I cannot remember this? It happened to so many people and wasted so much time.

But, I always ask people to see if they can run tools from the command line. If they can't, neither can we. We don't do any magic in that regard.

[andyinno]

Darn it. We are cursed by libncurses again. Why is it that I cannot remember this? It happened to so many people and wasted so much time.

Sadly yes, we are.

But, I always ask people to see if they can run tools from the command line. If they can't, neither can we. We don't do any magic in that regard.
Yes, I followed your advice and checked from the command line. Then the message was pretty clear about what to do.
Thank you again for your hint for discovering the problem

I am testing the setup right now.
I have both SWO output and step by step debugging.
It could be some kind of placebo effect but it seems to me that the step by step command are faster that in a native environment.

[mateusz-]

With WSL2 (Ubuntu 20.04) I also had to install libncurses (sudo apt install libncurses5) to get debugging to work.

[haneefdm]

@mateusz- It is not just you. Everyone has to do this. For some reason, this does not install automatically when you install gdb on any kind of Linux that I know of. WSL2 or not.