For a CubeSat project, we only have a single board available. But multiple universities and developers need to have access to that board for developing and debugging the firmware. We cannot easily ship around the board: That takes a lot of time, and during shipment, nobody can use the board.
There is a nice feature in the Segger J-Link software that allows sharing the debug connection over the network: the J-Link Remote Server. It even works nicely between different networks without complicated firewall setup:
Let's go over how to share a board for debugging with Eclipse, using J-Link and Eclipse with the GNU ARM Eclipse J-Link plugin.
I’m using the following versions (other versions or combinations do work as well):
- Host machine: could be Linux/Windows/Mac (I’m using Windows 10).
- Segger J-Link debug probe (any J-Link probe should work) with SWD/JTAG connection to the board.
- Segger J-Link Software: V6.12g.
- GNU ARM Eclipse J-Link Plugin: v188.8.131.52701141320.
- Eclipse Kinetis Design Studio: V3.2.0.
Segger Remote Server
To access the board from any other machine in the same network, I have to run the ‘Segger Remote Server’ executable on the host which has the board connected with a J-Link debug probe. With the IP address of the server host, I can use the board from the client host like a normal TCP/IP based debug probe:
To run the Segger Remote Server, on Windows there are two binaries: a command line version (CL) and a GUI version.
It directly connects to the J-Link attached on the server host:
Same thing if using the command line version:
To connect to the server, I need to use the IP address of the server host (e.g. use ipconfig command on Windows):
Now all I need to do from another machine to debug that board is to specify the IP address in the Eclipse Debugger launch dialog:
So, that way, I can debug that board as I would have a TCP/IP enabled debug probe available :-).
Both the command line version and GUI version accept some command line arguments:
Command line options: UseTunnel - Starts J-Link Remote Server in tunneling mode port - Select the remote port to listen on SelectEmuBySN - Select the J-Link to connect to by its S/N
By default, it uses the port number 19020. Using different port numbers, I can run multiple Segger J-Link servers if I have multiple probes connected to the server host. For example, I can use port 19021:
JLinkRemoteServerCL.exe -port 19021
With multiple Segger probes attached to the host, I can select it by the SelectEmuBySN option or in the dialog which offers to select the probe.
In the debug settings, I have to specify the port in the following way:
There is a bug in the current GNU ARM Eclipse plugin preventing typing in a colon (‘:’) for the IP address, which I have reported (https://github.com/gnuarmeclipse/plug-ins/issues/177). The workaround is to copy/paste the address/colon.
The above approach works if I’m in the same network and I’m able to connect to the server IP address. In the past, I have used VNC, dyndns, or VPN connections. But this is usually rather complicated to set up, especially if I’m not the administrator of the network. An easier way is to use the ‘UseTunnel’ option:
UseTunnel - Starts J-Link Remote Server in tunneling mode
I can use that option like this:
And it will start the server in tunnel mode. With this, it connects to an external server at:
By connecting from the client host to the Segger tunnel server, I can debug my board as it would be in the local network:
For the connection from the client host, I have to specify the Segger serial number:
If entering the ‘:’ does not work, use copy-paste until that issue is fixed in the GNU ARM Eclipse plugin.
That way I can debug the board through the tunnel:
For me, debugging through the tunnel is considerably slower, but it works well enough.
With the GDB Remote Server software, I can have a TCP/IP based debug probe and debug my board remotely with GDB and Eclipse. All I need is a Segger debug probe, a host machine, and the Segger Remote Server software running. With the tunnel mode, it even works between networks and allows me to share a board between remote developers. Of course, this is not as good as having the board on the desktop, but better than to physically ship a board around.