Volunteers needed to test OpenOCD/JLink with SEGGER Real Time Trace (RTT)

[haneefdm]

Updated: Aug 6, 2021, 7:12 PST SWO text output is now directed to a Terminal and so is output of GDB server (OpenOCD, JLink, etc.). This also enables bidirectional semihosting

I have a branch made for implementing RTT support in VSCode. The branch is called 'rtt'. There are a few things you need to get started

If you just want to install the extension in its current state see
https://github.com/Marus/cortex-debug/releases.

But, if you want to build from sources, clone and compile the extension (make sure you are using the rtt branch. See instructions here

I had to patch OpenOCD due to a race condition I kept running into that is available here (more on that later). Unfortunately, you have to build OpenOCD which is not a trivial task. But the public OpenOCD might work for you
https://github.com/haneefdm/openocd

You may need to install node so that it is available from the command line.
https://nodejs.org/en/download/ NodeJS installation is no longer required.

Most of my testing has been on a Mac and some on Windows.

console, binary and 'graphdecoders, very similar to what SWO supports. The text output of the RTT goes into a new Terminal. In VSCode (July 2021 release), you can peel a terminal and dock it in other places. You will have as many consoles as you have channels and they are bi-directional. There is quite a bit of customization. You have to use IntelliSense inlaunch.json` to learn more.

Here is a launch.json entry for enabling RTT

            "rttConfig": {
                "enabled": true,
                "address": "auto",
                "decoders": [
                    {
                        "port": 0,     // In RTT lingo, this is the buffer index (or channel)
                        "type": "console",
                    }
                ]
            },

Note: RTT has been enabled only for launch type debug sessions. attach will come soon after launch is working properly.

Technically, you can use VSCode to do all the setup and no decoders. You can then use SEGGERs free RTT tools if that is what you prefer. That method has certain benefits.

[haneefdm]

OpenOCD patch and why?:

• When you start openocd, you have to configure it for RTT from within TCL scripts or command-line options or via monitor commands.
• The problem is when to do a rtt start. If you call it too early, it may not find in SRAM, the RTT header or even find the wrong one from the previous run.
• OpenOCD tries to search for the control block (RTT header) only once and we don't initialize the RTT FW much after the main and I may have breakpoints before that.
• The patch I made will attempt retries with the specified (or default) polling_interval. The entire patch is less than 10 lines of changes but it did not work for me without it.

[haneefdm]

About input in RTT consoles. Both binary and console type decoders are bidirectional. You can enter characters in the terminal that your FW can read. But just like the classic getchar() for a desktop program, the FW does not see the characters as you type them until you press Enter/Return. Basically, it is buffered a line at a time. The terminals for RTT also behave the same way. But I have three modes for how input is handled using the launch.json setting called inputmode (this name may change)

• cooked: Default. This acts similar to a shell running in a pseudo-terminal. It supports line editing, history. The equivalent of stty cooked
• raw: No input processing or buffering is done. Characters are sent to the FW immediately. Not even backspace works as you expect and you can't see the chars being typed unless the FW echoes back the received chars (including newlines). The equivalent of stty raw
• rawecho: This is just like raw except for two things. Chars are echoed and newlines are handled by moving the caret down to the beginning of the next line. The FW still receives all the chars.

Also, you have a customizable prompt that is displayed if the last char seen was a newline.

[haneefdm]

Binary encoder This formatting was borrowed from the existing SWO binary decoder. In the following image, you can see a binary data dump (time - hex-value - parsed-value - scaled-value). You can also see that (to the right) I have two RTT channels going. The parsed value was unsigned and the hex value is little-endian and hence the hex bytes look like that. I would have preferred that the hex value had the bytes reversed but I went with what was already there. There is an argument for both ways

The following went into my launch.json (I had a bit more but this is all that is needed)

                    {
                        "port": 1,
                        "type": "binary",
                        "encoding": "unsigned",
                    }

[haneefdm]

The firmware I used the firmware that ships with JLink (it is free). It is also available here. https://github.com/adfernandes/segger-rtt but it is a bit out of date. It was as simple as adding all that source code into my FW project and calling one (or more) of the functions in the Example directory (every example has a main and renamed it and removed the forever loop, so I could call them from my main that does things other than testing RTT). I was using RTT in a real application.

[hwmaier]

Hi @haneefdm,
Thank you for all your great work on this plugin and publishing this pre-release and I am happy to test it.
I am currently using RTT with an official J-Link and a Renesas MCU using plugin version 0.3.13 and am quite happy with it. With this MCU you can't use autodetect (limitations relating to TrustZone) and I use the postlaunch command to configure the correct _SEGGER_RTT address based on the symbol table of the ELF file. This works quite well and I use Segger's GUI RTT Viewer as well as the command line based RTT Client then running in a VS Code terminal.

            "servertype": "jlink",
            "postLaunchCommands": [
                "eval \"monitor exec SetRTTAddr %p\", &_SEGGER_RTT", // https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/#j-link-rtt-client
            ],

Today I installed your plugin without any mods to my launch.json and straight away RTT stopped working. So the pre-release seems to break currently working setups. What happens is that the RTT client or viewer remain in the "Waiting for J-Link conenction" state.

So far I did not manage to get it to work, even after adding these settings:

            "rttConfig": {
                "enabled": 0x20003c48,
                "address": "auto",
                "decoders": [
                    {
                        "port": 0,     // In RTT lingo, this is the buffer index (or channel)
                        "type": "console",
                    }
                ]
            },

to my launch.json.

Does this extension not work with the J-Link tools and maybe only with OpenOCD? We can't use OpenOCD due to lack of support for TrustZone IDAU configuration. If it is limited to OpenOCD then I don't mind but it should not break RTT for J-Link users.

[haneefdm]

@hwmaier Yes, I inadvertently broke the JLink RTT by passing an extra argument that changed the RTT TCP port. I reverted that change. I updated the release but did not change the version# (it is a long process). So sorry about that. Could you try.

https://github.com/Marus/cortex-debug/releases/download/v0.3.14-pre1/cortex-debug-0.3.14-pre1.vsix

No, I have not done RTT support for JLink because I do not totally understand how it works with multiple RTT channels. I think I can figure out channel 0. I don't know what it does with more than one channel and how to set the address, etc. I was reading the manual when I saw your report

Would you share your whole launch.json? Also, we don't even look at rttConfig for anything other than

[hwmaier]

@hwmaier Yes, I inadvertently broke the JLink RTT by passing an extra argument that changed the RTT TCP port. I reverted that change. I updated the release but did not change the version# (it is a long process). So sorry about that. Could you try.

https://github.com/Marus/cortex-debug/releases/download/v0.3.14-pre1/cortex-debug-0.3.14-pre1.vsix

Good, this update fixes this. RTT now works as it did before.

Would you share your whole launch.json? Also, we don't even look at rttConfig for anything other than

See below an abridged version:

    "version": "0.2.0",
    "configurations": [
        {
            "name": "J-Link RA",
            "cwd": "${workspaceFolder}",
            "executable": "${command:cmake.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "runToEntryPoint": "Reset_Handler", // Avoid stupid "Exception"
            "servertype": "jlink",
            "armToolchainPath": "${env:ProgramFiles(x86)}/GNU Arm Embedded Toolchain/9 2020-q2-update/bin",
            "serverArgs": [
                "-silent"
            ],
            "postLaunchCommands": [
                "eval \"monitor exec SetRTTAddr %p\", &_SEGGER_RTT", // https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/#j-link-rtt-client
            ],
            "rttConfig": {
                "enabled": true,
                "address": "auto",
                "decoders": [
                    {
                        "port": 0,     // In RTT lingo, this is the buffer index (or channel)
                        "type": "console",
                    }
                ]
            },
            "preLaunchTask": "idautool",
            "postDebugTask": "reset",// CPU is in halt after a debug session, so make sure its running
            "device": "R7FA6M5BH", // No way to extract the device from somewhere (eg a file or setting)
        },
        {
            "name": "J-Link STM32",
            "cwd": "${workspaceFolder}",
            "executable": "${command:cmake.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "runToEntryPoint": "Reset_Handler", // Avoid stupid "Exception"
            "servertype": "jlink",
            "armToolchainPath": "${env:ProgramFiles(x86)}/GNU Arm Embedded Toolchain/9 2020-q2-update/bin",
            "serverArgs": [
                "-silent"
            ],
            "postLaunchCommands": [
                "eval \"monitor exec SetRTTAddr %p\", &_SEGGER_RTT", // https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/#j-link-rtt-client
            ],
            "device": "STM32F746NG"
        },
        {
            "name": "ST-Link",
            "cwd": "${workspaceFolder}",
            "executable": "${command:cmake.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "stlink",
        },
        {
            "name": "(Windows) Launch",
            "type": "cppvsdbg",
            "request": "launch",
            "program": "${command:cmake.launchTargetPath}",
            "cwd": "${workspaceFolder}",
            "externalConsole": false, // false requires setvbuf(stdout, NULL, _IONBF, 0), https://github.com/microsoft/vscode-cpptools/issues/5854
            "internalConsoleOptions": "openOnSessionStart",
            "logging": {
                "moduleLoad": false,
            }
        },
    ],

And then I launch manually external Segger RTT viewer using these entries in tasks.json:

    "tasks": [
        {
            "label": "J-Link RTT Client",
            "type": "process",
            "command": "${env:ProgramFiles}/SEGGER/JLink/JLinkRTTClient.exe",
            "presentation": {
                "panel": "dedicated"
            },
            "problemMatcher": [],
        },
        {
            "label": "J-Link RTT Viewer",
            "type": "shell",
            "command": "start \"\" \"${env:ProgramFiles}/SEGGER/JLink/JLinkRTTViewer.exe\" -if swd -s auto -a",
            "problemMatcher": [],
        },

and in settings.json I have:

    "cortex-debug.JLinkGDBServerPath": "${env:ProgramFiles}/SEGGER/JLink/JLinkGDBServer.exe", 

[hwmaier]

And with the channels I would not bother too much about, I expect most would only use a single channel (eg 0).

[haneefdm]

@hwmaier I got JLink RTT viewer working for Channel 0. Anything other than channel 0 has many issues

[haneefdm]

@hwmaier Checkout the JLink support (with some limitations placed by their gdb-server)

https://github.com/Marus/cortex-debug/releases/tag/v0.3.14-pre2

@hwmaier , when starting the RTT session, sometimes, I see data from a previous run. I was able to mitigate that with OpenOCD but I am unable to do the same with JLink gdb server

[hwmaier]

Hello @haneefdm,

Wow, yes this works nicely. Even with colouring. Great work, thank you so much for spending all these hours on this feature.

One thing I would have on the wish list, would be to automatically change the focus and activate the RTT terminal once you hit F5 and start debugging. Maybe this can be a setting like "autofocus".

In my workflow I hit F5 and it would compile the code and then the focus stays on the "OUTOUT" tab and I have to click on the "TERMINAL" and then select the "RTT Ch:0" console to see the output (there may be other terminals open as well).

The other suggestion releates to the "RTT-0>" prompt. When a lot of scrolling happens the prompt flickers which can get visually very irritating. Maybe the line where "RTT-0>" is printed never should be used for terminal output so it does not require to be cleared and overprinted. See below animated gif:

[hwmaier]

... and I wonder I may renaming in launch.json port to channel would be more intuitive to a user as this would match Segger's terminology.

BTW, automatic address setting seems to work as well. I don't need this line any more in my launch.json:

                "eval \"monitor exec SetRTTAddr %p\", &_SEGGER_RTT", // https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/#j-link-rtt-client

as I needed with Segger's viever or console. Nice.

[haneefdm]

@hwmaier Thank you.

About changing focus: I tried to do that and the code to do that is still there. The problem is too many other windows think they are the most important in the world and they are coming to the foreground. When you start a debug session, there are at least 4 different things going on. One thing you can do is to drag the RTT terminal into another area (like the editor or to the left) and it will live there. Since I re-use the window as much as possible, it will stay put until ..... something crashes :-)
https://code.visualstudio.com/updates/v1_58#_terminals-in-the-editor-area
Here is a Small video when the feature was in preview
It won't remember and I cannot create it where you want it. No API for that.

About the prompt: You can choose to have no prompt (or a tiny one) at all from launch.json. That terminal does not have many options so putting it at the bottom is not possible unless I do the entire terminal (I am borrowing what is there). What I was looking at doing is to possibly wait until idle time to display the prompt. There is no idle event available so I have to make one up. I will work on the second option.

No, can't change the 'port' working that easily. It will break SWO (lot of common code and data structures). A ton of work. I have to see if I can use a channel as an alias (package.json is super limited). In the code it is already confusing (port could mean RTT channel, SWO/ITM port, tcpPort, etc.)

Yes, I automatically pickup up the symbol address if one exists -- from the elf executable though.

BTW, JLink does not and cannot use more than one channel and it pretty much HAS to be channel 0. OpenOCD using the same FW gives me a tcp-port per channel. My plan is to use additional channels to stream binary data that can be plotted/graphed.

[hwmaier]

Ok, I wasn't aware that you essentially re-use the integrated terminal which sadly has some limitations regards focus/activations.

The noprompt option works and avoids the flicker issue.

I have a suspicion that Segger's JLinkGDBServer.exe allows only one telnet connection while their own RTT Viewer tool bypasses the JLinkGDBServer and uses the J-Link DLL directly and as such can offer multiple channels.

Regards the channel 0 limit, I think this covers 90% of use cases and you will make a lot of embedded coders happy with what you have implemented so far. So don't concern yourself too much with the multi-channel feature. And if I ever would want to use multiple channels, then I can use Segger's RTT Viewer in those situations.

[hwmaier]

I had some situations where after re-start of a debugging session the RTT console is gone and I get this little error message.

This also happens when I drag the console into an editor window, stop the session (F6) and then restart (F5).

[hwmaier]

Re JLinkGDBServer, are you using the undocumented -rtttelnetport command line option to set the RTT terminal port?

https://wiki.segger.com/RTT
Here it says "...the RTT Channel can be set via a SEGGER TELNET Config String. The default channel is channel 0 (Terminal)"

So the channel can be set using some magic strings you have to send straight after the connection.

https://wiki.segger.com/RTT#SEGGER_TELNET_Config_String

[haneefdm]

I had some situations where after re-start of a debugging session the RTT console is gone and I get this little error message.

This also happens when I drag the console into an editor window, stop the session (F6) and then restart (F5).

That would be a bug. I will try to reproduce it when I have some HW with me.

Off-topic. May I ask what the issue is with TrustZone and OpenOCD? I will run into this soon and will become a huge personal problem for me!!

[hwmaier]

The TZ issue I mentioned relates to Renesas RA MCUs only. It would probably not affect others and is caused by the way Renesas requires the TZ IDAU partitions to be set. This cannot be done using SWD and can only be done using a serial port and they have implemented the protocol in a tool which only interfaces either with the J-Link DLL or their own e2 debugger probe. Until someone replicates this in OpenOCD, J-Link is the only option for now. I already have implemented a tool to set the IDAU partitions using a command line tool so I can use VS Code rather having to use Eclipse, refer to https://github.com/hwmaier/idautool

[haneefdm]

I think that Wiki page says that while the default channel is 0, you can change it. But still, just one channel per session. Thank you for TZ info.

[hwmaier]

Correct. One would need multiple telnet sessions, one per channel, but that wouldn't be that bad as the sessions are tabbed.

[haneefdm]

Hmmn, I already handle multiple telnet sessions with OpenOCD. Much cleaner. With JLink, there can only be one (max) telnet session, except they provided a way to select a channel for that session.

I am looking at a threaded application where each thread would own to a channel. With SWO, there is only one session (one pin) but each packet has info on which ITM port it belongs to.

[hwmaier]

I had another good look at the functionality of Segger's RTT Viewer application. It is essentially nothing more than a telnet client and connects using port 19021 with the JLinkGDBServer. I figured this out with Wireshark. RTT Viewer only supports channel 0 and I think I confused channels with terminals. As Segger's own tools support only one channel, I don't think users would expect more from the cortex-debug plugin.

[haneefdm]

Yes, SEGGER is usually really responsive if actual customers ask for something. I will try to contact them after I release what I got. Yes, the virtual terminals are pretty hackish even from a usage point of view. In my current build, I do detect those switches and print it out. If you are logging to a file, then you can at least tell which line belongs to which "virtual" terminal.

###### Testing SEGGER_printf() ######
printf Test: %c,         'S' : S.
printf Test: %5c,        'E' : E.
<switch to vTerm#2>
printf Test: %-5c,       'G' : G.
printf Test: %5.3c,      'G' : G.
printf Test: %.3c,       'E' : E.
printf Test: %c,         'R' : R.
<switch to vTerm#3>
printf Test: %s,      "RTT" : RTT.

Btw, I implemented the "prompt at idle time" feature and you should not see that shimmering anymore. I will make a build maybe later today.

I now have a problem with JLink where if you do type something in the terminal, the server disconnects. I can reconnect but now the stdin is totally broken on my side. This is a bidirectional channel so I don't understand. Not a problem with OpenOCD. Not sure what I am doing wrong. Aaaargh

[bmcdonnell-fb]

[EDIT: Quoting @hwmaier from up thread:]

RTT Viewer only supports channel 0

Mostly correct. Per the J-Link RTT Viewer wiki page,

J-Link RTT Viewer ... supports:

• Displaying terminal output of Channel 0.
• Up to 16 virtual Terminals on Channel 0.
• Sending text input to Channel 0.
• Interpreting text control codes for colored text and controlling the Terminal.
• Logging terminal data into a file.
• Logging data on Channel 1.

(Emphasis mine. Also, I see the same text on the RTT Technology page, and in UM08001_JLink.pdf.)

Also note, this very recent forum post highlights that "an RTT terminal and RTT channel are two different things." See the Terminal Tabs section of the wiki page for details.

Per section 16.3.3 RTT Logger in UM08001_JLink.pdf, I see that data can be received on RTT channels 1+ using "J-Link RTT Logger".

[haneefdm]

@bmcdonnell-fb Yes, I know that the virtual terminals are very different from actual channels. The logging tool is an offline tool and does not cooperate with a debug session. Here, I am trying to do all of that with one tool. The existing JLink tools (Viewer, Client & Logger) can be used standalone (or while debugging with Cortex-Debug) as always.

We want the additional channel functionality in the JLinkGDBServer which would be most useful.

[hwmaier]

@haneefdm Hi Haneef, let me know if I can assist with debugging the issue with the RTT console disappearing (#456 (comment)). This happens so frequently to me that I stopped now using the rtt feature of the extension. Maybe I can enable some logs etc. Also happy to stuff some debug log traces into the JS code if you give me some pointers.

[hwmaier]

Also re your comment "There is another artifact with channel 0 where you may see output from a previous run at the very beginning.", have you tried latest SEGGER RTT library v7.52? I saw some changes in there relating how the buffer is initialised and the marker set compared to v7.50.

[haneefdm]

I haven't made another release, but I pushed LOT changes that may make things a bit easier. Too many changes though.

I am using SEGGER 7.50a, but I did not update the FW. Downloading 7.52 now.

I am not seeing that "Duplicate channel" at all. I do dozens of restarts a day. Can you help me with step by step? The method of re-cycling Terminals for the next session has changed dramatically, so maybe it is fixed now. It did happen once. When a window disappears, that usually means there was a crash or the extension thought it was no longer being used and purged it. If you are not seeing the RTT window at all that means we think it is already running.

I now have a global try/catch to display if something went wrong and hang around so that the window does not disappear. You may even see a stack trace.

[haneefdm]

Btw, when things go bad, try "Reloading the Window" (in Command Palette)

[haneefdm]

I tried 7.52a, and it is identical to the one I am using. But, I figured out the issue with why I see stuff from a previous run on a start. That is because JLink does not disconnect as per protocol. The FW continues to run after to detach from the debugger. OpenOCD is different. So when I restart the application, my application was actually running after the previous session. Hence there is stuff in the channel buffer.

I can prove it with a simple blinky app. We just have to live with that.

[hwmaier]

I tried 7.52a, and it is identical to the one I am using

Good. Because the version from this repo (#456 (comment)) is different and official v7.52 has this interesting comment:

  // Copy Id string backwards to make sure that "SEGGER RTT" is not found in initializer memory (usually flash),
  // as this would cause J-Link to "find" the control block at a wrong address.

The FW continues to run after to detach from the debugger.

I also noticed this annoying "feature" with J-Link and wonder if one needs a JLinkScript or command file to tell J-Link to put the target on hold/stop when not debugging.

[haneefdm]

Yes, I mitigated what they did in FW by starting clearing the search string area, if I knew the address. Now I don't have to do that for JLink. At the beginning of a launch, you will see four 32-bit writes before I enable RTT

I gave that link for RTT FW, so it would be easy for people to find. I will update it.

[hwmaier]

I gave that link for RTT FW, so it would be easy for people to find. I will update it.

People would assume (like I did) this link would be a canonical repo and point to the official version, but it does not. That repo also has slightly modified config headers and I think one cannot trust it to always track Segger's originals.

[hwmaier]

Hi @haneefdm, I just saw that you released a new pre-release version 0.4.0-pre1. That one works very well.

I have 3 points I observed while using the pre-release:

1. I saw that you hardcoded the JLinkGDBServerCL option -nogui into the launch commands. And this cannot be changed. I find the dialog box is really useful to see what's happening, in particular for devices where the flashing is rather slow. Could we have the old behaviour reinstated and the user can always remove to box by adding serverArgs: ["-nogui"] if desired.

2. I noticed, when stopping debugging, I see on the terminal this error log message:

Error: read ECONNRESET

3. I still get occasionally, but less frequently than with 0.3.4-pre2, this message and then the console is not available. But it seems to recover once I re-start the debugging session.

Tested with latest 7.53c Jlink dll and JLink RTT lib.

Thank you for all you work.

[haneefdm]

Thanks,

There was a problem without the -nogui option. A tcp port was grabbed by another JLink process and that process would hang around even after the server exits, causing issues in quick restarts. I will remove that option.

I will continue to look at the duplicate port issue. Should not be happening. I cannot duplicate it. I did find a bug earlier by just reading the code but it never happened to me (Macbook Pro 16"). Can you think back and retrace your steps to just before it happens?

The ECONNRESET, I get it very rarely (so I left the debug message there, but this is a case where the server closed the port while it is being read on the other side. NodeJS (rightfully) throws an error instead of treating like an EOF. Kinda race condition. It is safe to ignore, just wanted to know how/why it is happening. I know now and this error message now filtered.

Did you notice that the gdb-server now gets its own Terminal?

[hwmaier]

I will continue to look at the duplicate port issue. Should not be happening. I cannot duplicate it. I did find a bug earlier by just reading the code but it never happened to me (Macbook Pro 16"). Can you think back and retrace your steps to just before it happens?

Well, there is little special I do. I press F5 then Click the Debug Stop icon (the red square) and then repeat this procedure a few times. It happens when I do repeated debug sessions without changing the code. It happens less frequently now, but let's says 1 out of 10 debug/stop cycles.

Did you notice that the gdb-server now gets its own Terminal?

Yes I did notice but I never see any output there.

[haneefdm]

Yes I did notice but I never see any output there.

You should see all the output from JLink there. The terminal is cleared when a new session starts but the current/previous session contents should be there. It is possible that if you start and stop real fast, the terminal has already cleared. But you should at least see a message Waiting for gdb server to start... or GDB server exited. Waiting for next server to start...

I made a minor change to see if the Duplicate port issues go away. It shouldn't but if it does something is not right in the debug-protocol. Means a session is starting while I am still cleaning up the previous one. It is all asynchronous -- but single-threaded so this should not be happening

[hwmaier]

Regards the outputs on the various consoles. I get these outputs:

Obviously the build console from cmake:

Debug Console with gdb's output:

Jlink DLL's output appears on "Output - Adapter Output":

Nothing on

So I am quite happy to have JLLink's output in the "Output - Adapter Output" console rather in another terminal. Or do I misunderstand something?

[haneefdm]

Hmmm, not sure what is wrong. I am intentionally outputting to both 'Adapter Output' in 'OUTPUT' tab (old method) and into a terminal. After you stop a session, do you see any text in that Terminal?

I HAVE to make the terminal thing work and when it does, I will remove the 'OUTPUT' stuff. In the terminal, it can have bi-dir IO -- needed for semihosting, a long-pending request. Also, it cuts down on the number of Issues/emails because people have a tough time finding it. Can't make a full release without this working. It works without issues on both Windows and Mac for OpenOCD/JLink

[hwmaier]

Interesting indeed. We have totally different behaviours with this and I wonder what makes my system behave differently.

After you stop a session, do you see any text in that Terminal?

Never saw any text in there.

I HAVE to make the terminal thing work and when it does, I will remove the 'OUTPUT' stuff. In the terminal, it can have bi-dir IO -- needed for semihosting, a long-pending request. Also, it cuts down on the number of Issues/emails because people have a tough time finding it. Can't make a full release without this working. It works without issues on both Windows and Mac for OpenOCD/JLink

Ok I understand now the reasons why the output is moving from OUTPUT to TERMINAL. If it has to be two-way, eg requiring user input, then this is the only option. And I agree, it is easier to find, you don't have to dig through all the OUTPUT selections.

This is my current launch.json setting:

        {
            "name": "J-Link STM32",
            "cwd": "${workspaceFolder}",
            "executable": "${command:cmake.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "runToEntryPoint": "Reset_Handler", // Avoid stupid "Exception"
            "servertype": "jlink",
            "serverArgs": ["-gui"],
            "armToolchainPath": "${env:ProgramFiles(x86)}/GNU Arm Embedded Toolchain/9 2020-q2-update/bin",
            "rttConfig": {
                "enabled": true,
                "address": "auto",
                "decoders": [{"port": 0, "type": "console", "noprompt": true, "clear": false }]
            },
            "device": "STM32F207IG"
        },

and these are settings.json entries I believe are relevant:

    "terminal.integrated.shell.windows": "C:\\Windows\\System32\\cmd.exe",
    "terminal.integrated.tabs.enabled": true,
    "output.smartScroll.enabled": false,
    "debug.onTaskErrors": "abort",
    "cortex-debug.JLinkGDBServerPath": "${env:ProgramFiles}/SEGGER/JLink/JLinkGDBServerCL.exe", 

Running VS Code version 1.59.0

Now what can I do to help you figuring out the difference in behaviour?

[PhilippHaefele]

Tested the RTT support with:

• Windows 10
• VSCode 1.59.0
• Segger J-Link Pro
• J-Link GDB Server V7.00a
• Local build of 96fdd32 (BTW thanks for the "How to Build from sources" section)

Launch config:

{
      "name": "Debug",
      "cwd": "${workspaceRoot}",
      "executable": "${workspaceRoot}/build/abcd.elf",
      "windows": {
          "serverpath": "C:\\Program Files (x86)\\SEGGER\\JLink\\JLinkGDBServerCL.exe",
          "armToolchainPath": "C:\\Program Files (x86)\\GNU Tools ARM Embedded\\8 2019-q3-update\\bin"},
      "linux": {
          "serverpath": "/usr/local/bin/JLinkGDBServer",
          "armToolchainPath": "/opt/ARM/gcc-arm-none-eabi-8-2019-q3-update/bin"},
      "request": "launch",
      "type": "cortex-debug",
      "servertype": "jlink",
      "device": "STM32F777NI",
      "interface": "swd",
      "runToEntryPoint": "main",
      "serverArgs": [
          "-rtos",
          "${workspaceRoot}/RTOSPlugin_uCOSii"
      ], // we're not using the rtos option as there we need to pass the full path -> raise issue on GitHub to allow ${workspaceRoot} in rtos option
      "svdFile": "${workspaceRoot}/STM32F7x7_v1r2.svd",
      "postLaunchCommands": [
          "set variable OSTCBList = 0",
          "set variable OSIntNesting = 0"
      ],
      "rttConfig": {
          "enabled": true,
          "address": "auto",
          "decoders": [
              {
                  "label": "",
                  "port": 0,
                  "type": "console"
              }
          ]
      },
      "debugServer": 4711
  }

Had some issue at my setup in the past (needed the SetRTTAddr and/or manual set of RTT address) when using RTTViewer.

The integrated solution works like a charm on my side 😄 👍

Thank you very much for going into the effort of integrating this.

[haneefdm]

@PhilippHaefele Thanks for trying it out. We still have a ways to go before I can release it.

Oh, you are using the 'rtt' branch. It is changing 2-3 times a day btw. I try to keep it as stable as possible.

[haneefdm]

Coming today. Now, you can plot RTT data (especially with OpenOCD) just like you could with SWO

The procedure is the same as what is described for SWO. Wherever it says port, it is the same as an RTT channel. We may support the use of channel later or we just get used to it :-)
In the plot above

• I wrote binary data to RTT channel How to Support or Donate? #1 in FW. You have to initialize channel#1 first. Only Channel#0 is auto initialized. In my example, I was using some random numbers normalized to 16 bits. Data read by Cortex-Debug however is always 32 bits at a time.
• Configured a decoder to read binary data of type graph.in launch.json. I set the graphId to "ABCD"

                   {
                        "label": "",
                        "port": 1,
                        "type": "graph",
                        "encoding": "unsigned",
                        "graphId": "ABCD",
                        "scale": 0.5
                    }

• setup graphConfig to create the plot. I used the graphId created above. I used a timespan of 5 seconds

            "graphConfig": [
                {
                    "label": "Graph 1",
                    "timespan": 5,
                    "type": "realtime",
                    "annotate": false,
                    "maximum": 66000,
                    "minimum": 0,
                    "plots": [
                        {
                            "graphId": "ABCD", 
                            "label": "abcd",
                            "color": "#53753c"
                        },
                    ]
                },
            ],

I reused all the wonderful infrastructure that @Marus had already created and hooked it up to the RTT channels. Notice that the plots is an array meaning that you can plot data from multiple graphId.

[haneefdm]

New release published. Again quite a bit changed internally. Improved terminals and support for plotting/graphing. See comment above

https://github.com/Marus/cortex-debug/releases/tag/V0.4.0.pre2

@hwmaier hopefully the gdb-server terminal is working now. I was only able to reproduce it on Windows with a production build. The backend is much faster than the front-end where the GUI stuff lives. The server launched and exited before the frontend even had a chance to prepare. This will still be the case but the output will not be lost. It was actually a problem with VSCode Terminal API. It implied synchronous but it is not. It takes a (long) while for the terminal to actually accept text. Thanks, @hwmaier for reporting the problem and helping me.

[hwmaier]

TaTah! Look what we see here now:

and

I like the way you differentiate the log message's origin by colour.

I think your release is ready for prime time. Why not even marking it as 1.0, you added so many cool features,.,

[haneefdm]

With your help, I finally published the release.

https://github.com/Marus/cortex-debug/releases

Fingers crossed. Special thanks to @hwmaier for the encouragement, testing, and feedback. Btw, this is not my extension so I did not bump up the release to 1.0.0.

Comments are still welcome but I am closing this issue