Feature Request: JLinkRTTClient

[abeck70]

Seggers RTT is an excellent debug print out and also trace tool:
https://www.segger.com/products/debug-probes/j-link/technology/real-time-transfer/about-real-time-transfer/

In particular I use JLinkRTTClient : "J-Link RTT Client acts as a Telnet client, but automatically tries to reconnect to a J-Link connection when a debug session is closed. The J-Link RTT Client is part of the J-Link Software and Documentation Pack for Windows, Linux and macOS and can be used for simple RTT use cases."

I manually start and stop this for each debug session.

A minimal feature request would be to start and stop this, similar to a semihosting session but better.

See here for a side by side comparison:
https://blog.segger.com/getting-printf-output-from-target-to-debugger/

[Marus]

I was considering for the future to actually directly connect to the RTT telnet server and channel that data into the Visual Studio Code interface - but haven't had time to look at implementing this. This would of course not have the "but automatically tries to reconnect to a J-Link connection when a debug session is closed" functionality from the JLinkRTTClient utility.

There is an issue already open for Visual Studio Code itself for a "postLaunchTask" attribute on debug requests (microsoft/vscode#2405). That would cover launching the JLinkRTTClient executable itself if you want to use the built-in functionality that I intend to write. While it is not available yet - it does appear that it is actively being worked on - so I expect it will be available soon.

[cHemingway]

If anyone is looking for a temporary solution for this, I use KiTTY, which is a fork of PuTTY with an auto-reconnect option.

Telnet to localhost, port 19021, and then set it to auto-retry, and whenever I restart a debug session it reconnects automatically after a second or so, unlike J-Link RTT Viewer which seems to have broken auto-reconnect support for me.

Since VSCode doesn't support having the debug console and terminal visible at the same time, I prefer having RTT in a seperate window for now, although apparently multiple/detachable terminals is on the Roadmap

[LostTime76]

Erm... I am wanting to have some RTT like functionality too; however, the issue posed here seems like the jlinkgdbserver is killed after a debug session stops. In this case, your RTT connection could also be killed. Why not just provide the option for the launch.json or whatever to connect to an already running jlinkgdbserver that the user starts themselves? The user controls the lifetime of the server, not the plugin. The plugin is just another consumer of the server.

I understand the 'want' to make stuff automated like the command line by starting and killing the server. However, the user knows the lifetime of the server better. Additionally, it is not very difficult to use the vscode task worker plugin to create a button that can launch the gdbserver.

I am not specifically wanting to use RTT; however, I do want to be a consumer of the server alongside the plugin with my own application. With this I can read and write memory at runtime alongside the plugin without worrying if the plugin is going to kill my gdbserver instance.

To make this happen, seems like you would need to add a few parameters or have someway to specify that you want the plugin to attach to an already running instance of jlinkgdbserver. Since I am assuming that the plugin just launches the gdbserver itself and connects to its IP, this really should be trivial. However, I am not super familiar with the source code of this plugin so pardon the ignorance.

[haneefdm]

@LostTime76 There are many issues with keeping the server running. For instance, if you stop + start the debug session we have no information from the previous session and we would end up creating a new session so that would fail spectacularly. So far, our objective is to serve the 90+ use case. Having said that...we kinda have a solution

You can launch any gdb server yourselves and ask this extension to use it. Set servertype to external and supply a gdbTarget to connect to a host:address of your choice anywhere in the world. You can have the server running anywhere for however long you want. We have a generic startup sequence but you can override it all you want.

To help with how we normally start the gdb server, you can peek into the Debug Console

[LostTime76]

I don't see why it matters if you have no information from the previous session. The lifetime of the gdbserver would be the responsibility of the user. If the user doesn't properly sequence stuff, it will break. Tough luck. If on the other hand you want the plugin to automatically start & kill a server, well - there's the option.

With the external gdb server, aren't you providing exactly what was asked in my comment? I don't see how this is any different than what I asked.

By the user taking it upon themselves to manage the lifetime of the server, then they may have to run the command lines for programming and what not themselves. This is not an issue. I can manually write up a command to program a device and then run an attach command via your server external option. As long as attaching to an already running server has the standard controls: run, stop, break, restart, I don't see an issue. After the programming command is finished and the jlink program exits, I couldn't care less if part of my program runs far enough before I grab it via your plugin attach.

[haneefdm]

@LostTime76 The external server is our current solution. A lot of thought went into it to handle many situations. Not sure you have tried it. Both launch (with programming) and attach still work without any much customization so long as your gdb-server/device is not weird. Many users using it successfully. From within launch.json you can override EVERY command sent to the server.

If there are issues, then please report them and I will do my best to address them.

But, you seem to know more than me, so feel free to modify the extension and test for every server/device out there.

[LostTime76]

I have not used the plugin before. I am doing an evaluation of debugging tools based on my particular requirements. I never said I knew more than you, I am just stating my own situation. I don't have any intention of modifying the extension.

I am pointing out that a lot of people get stuck in trying to solve niche use cases that don't matter in the grand scheme (in my opinion), and when you were saying something about not having information about the previous session being a problem, I don't see that as a problem unless you are trying to automate every niche use case. Not every case needs to be solved as long as the user can do what they need to. If it requires a few more manual operations to get the flexibility needed, then so be it.

Additionally, running the jlinkgdbserver manually and having the user manage the lifetime of the server instead of the plugin, seems to solve the original RTT requirement (and mine) posted by the OP assuming the plugin has a way to connect to the server without starting or killing the process. It looks like this case is solved.

What more is there? Do you want to try and start / leave the process running between sessions automatically? If you want to spend time coming up with a solution to that, be my guest; however, you have shown me that the external option exists, so I am set on my requirements.

[haneefdm]

See Issue #456 if you all are still interested in RTT -- there is a preview of a solution for RTT

[PhilippHaefele]

As #456 is merged and released with V0.4.0 i propose to close this issue

[haneefdm]

Thanks, I forgot to close it.