RTT support

[bugadani]

Implementation is based on SWO. Currently output is read from the telnet server and I think this makes it a bit slower than ideal.

I think a lot of this could be refactored together with SWO under a common IO implementation, but there are some differences and I didn't want to mess anything up in the process.

A screenshot of the feature working:

Limitations:

• I think it's not possible to select two channels at once

Differences with SWO:

• Only console decoder is implemented, but graphing and advanced can be introduced later or even in this PR. Advanced decoding can only work with one channel unfortunately, I think it's hopeless to sync multiple socket connections.
• There's a timestamp configuration that's off by default - this can be changed to on by default and also ported over to SWO easily enough.

[haneefdm]

Looks good to me and feels very well done. I have limited experience with RTT and not sure how to test the patch and use cases. Technically, RTT should work with all gdb-servers. Some screenshots of the end result would have been nice.

I am going to leave it to @Marus to review as he is more experienced and was always wanting to support RTT

[bugadani]

Technically, RTT should work with all gdb-servers

I could only test with J-Link server, and the implementation kinda relies on it, i.e. the segger telnet server must run. Allowing only for j-link was the safest option for me and I would like to leave lifting this restriction to people who can test.

I'm not sure what a screenshot would show - it looks the same as with SWO, except it says RTT :) But I can make one in the near future.

[haneefdm]

If it is working with JLink then that is all that matters. For now.

But please make a screenshot when you get a chance.

[bugadani]

I've added a screenshot and some remarks to the PR description.

[FacepalmMute]

Why are you don't merge this to master?

[haneefdm]

@FacepalmMute Not sure who you are addressing

I don't own this repo and don't have experience with RTT. I want the @Marus to approve this. I wish I had a way to test this so I can approve the merge

[FacepalmMute]

@haneefdm Ok, was just wondering when this would be merged.

I will test this feature until then and let you know if i find some errors.
RTT support would be very helpful :)

[legoabram]

@bugadani I'm so excited to have this! I just have a few things to mention from my own testing:

1. The output seems to be locked to a specific line width which I don't think should be happening. This may be based on the telnet socket, but I feel like we should let the console width determine the line width if we can.
2. The console doesn't process color input codes. At the very least, I think these should be ignored if it isn't possible to change the color.

[bugadani]

@legoabram to be fair, I merely copied and adapted the SWO code, with all its limitations. The 80 character line-width is a result of manually injecting newlines. I don't know what the output panel in VS Code can do, I never bothered to find out.

That said, these improvements could be useful even for SWO.

Oh, and I don't really expect this patch to be ever merged.

[Marus]

Well - I am going to start looking at RTT support (sorry have been on a long hiatus from being able to work on the project).

SWO doesn't generally have colors in the output - so that was something that wasn't handled there and would need to be a new addition (if that is somehow supporting them or just stripping the colors before output I'm not sure which - I'd have to do a bit of research to see what VSCode is capable of now).

Again, the 80 character word wrapping is something that might not make sense (and to be honest I'm not 100% sure I'll keep it in SWO)

[jhbruhn]

Hi, I'd love to add OpenOCD support to this, as it seems that it is only one or two OpenOCD commands away. I see this PR has merge-conflicts. @bugadani are you still on this PR and would update it so it can be merged, or is this the wrong approach @Marus ? If there is the chance that this will be merged, I'll wait with my implementation for OpenOCD. Otherwise I guess I'll just do a private fork of @bugadani s repo for now.

[Marus]

At the moments there are a number of conflicts due to the recent changes. I need to look in more detail and determine what other changes would really be needed.

The biggest thing that I know of that wasn't handled in the PR is the issues with the colors (and possibly dropping the word-wrapping). I'm hoping to get a chance to actually try to look at this on the weekend to see if it is close enough for me to merge into main-line - even if only as an experimental feature.

I hadn't realized OpenOCD had any support for RTT - but would be happy to get the OpenOCD support once this does get merged in.

[tarek-bochkati]

I hadn't realized OpenOCD had any support for RTT - but would be happy to get the OpenOCD support once this does get merged in.

FTR, RTT support was merged in the official 0.11
ref http://openocd.zylin.com/#/c/4055/

[yoonlee95]

This feature is the main blocker for our team to not being able to move from segger embedded studio to vscode. Will be looking forward to this being merged!

[bmcdonnell-fb]

Additional info regarding RTT support in OpenOCD:
http://www.openocd.org/doc/html/General-Commands.html#Real-Time-Transfer-_0028RTT_0029

[bmcdonnell-fb]

Just to tie together related discussions: I think this PR would address #39.

[haneefdm]

Saw that a couple of days ago. It was good news to see that from OpenOCD. I have to merge and build my OpenOCD for the device/boards I use to test it because that device has customizations that are not in the standard release :-(

@bmcdonnell-fb What is your setup? I do have a couple of o ST boards that maybe I can use? If I can use the OpenOCD out of the box, it would be great.

[haneefdm]

Your setup for HW (boards, probe, etc.)

…

On Fri, May 14, 2021 at 10:42 AM Brendan McDonnell ***@***.***> wrote: @haneefdm <https://github.com/haneefdm> my setup for what? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ23STYRG4PVIPYKJAO2TNTTNVOIZANCNFSM4RKTDSUA> .

[bmcdonnell-fb]

@haneefdm I'm using an ST-Link V2 with OpenOCD. Our RTT output comes via SWDIO, not SWO. I'm starting a telnet server on the host to provide the RTT output like this example.

https://ferrous-systems.com/blog/gdb-and-defmt/#defmt-print

Then I access it via whatever telnet client. (I recently found KiTTY, which has a handy auto reconnect feature.)

[haneefdm]

@bmcdonnell-fb I never tried that combo. When I used ST, I never used OpenOCD. This will save me a LOT of time.

Thanks for the pointers

[haneefdm]

@bmcdonnell-fb Do you mind sharing your launch.json? DId you have to create any additional config/tcl files for OpenOCD?

[haneefdm]

I created an env. for RTT and it works kinda on simple stuff. I see a race condition between starting rtt rtt start and the program running. I see several problems.

• Depending on what is the RTT control block, RTT spews out garbage from a previous run. I can live with that to some extent.
• OpenOCD can also try to read arbitrary address and fail because it is reading the RTT info from the device before it is initialized
• There is a race condition and a deadlock as well
  • If my program starts writing in blocking mode and it has written enough that the buffer is full
  • At the same time OpenOCD tried to read the RTT info when it was not ready and it gives up and never attempts again
  • Now, my program in the MCU is deadlocked -- waiting for the gdb-server to drain the buffer but that never happens
  • Problems are a bit different with 'runToMain' false vs true but there is still a deadlock.

Now, all my observations may not be correct but something is not right. The deadlock is REAL. I have to debug the OpenOCD source to see what is actually going on. There is no handshake between RTT FW and the gdbserver to notify when it is ready. Not sure how JLink handles this or if this is a problem in JLink as well.

Note that with all of this, CortexDebug is not even involved.

[hwmaier]

Just came across this PR and think that would be a nice feature indeed.

I currently use "postLaunchCommands": [ "eval \"monitor exec SetRTTAddr %p\", &_SEGGER_RTT", to auto-configure the RTT address in launch.json and use the JLinkGDBServer.exe as gdb server and have a terminal session running with JLinkRTTClient.exe. This sort of works but I would prefer the RTT client to automatically launch and stop and the console automatically switch to the VS Code Terminal so I can see instantly the debug output after hitting the "F5" key.

So I am looking forward seeing this PR to go mainstream.

[haneefdm]

See Issue #456 RTT support has been added, so I am closing this PR as it conflicts with a different implementation. I did get some ideas from this PR, so thank you for submitting it.