Writing separate ITM ports to separate files or named pipes for J-Link debugger

[jacek-s]

Would that be possible to have data output on separate ITM ports split to different files/pipes for JLink debugger?

Specifically I'm talking about a scenario where one would be able to do as follows:

• write ITM port 0 to SWV console
• write ITM port 1 to file: /path/to/file-a.txt
• write ITM port 2 to file: /path/to/file-b.txt
• write ITM port 3 to named pipe: /path/to/pipe

Personally to me the ability to log to files or to named pipes is equally important, as it applies to different use cases. Logging to multiple files based on the stimulus port opens the ability to selectively log separate system components or on separate logical logging levels. Writing data to named pipes opens the ability to use tools that utilize them, e.g. Wireshark, which would enable live view on the network traffic happening on the device on multiple interfaces at once.

The ability to log to files done on this level would also fix the issue where current generic logging (Debug Configurations -> GDB SEGGER J-Link Debugging -> Common -> Standard Input and Output -> Output File) consists of interleaved JLinkGDBServerCL and Semihosting and SWV outputs with no option to disable the former. That's probably a topic for a separate discussion though.

[ilg-ul]

I guess it can be done, but what is the advantage of using custom ITM ports instead of the standard semihosting?

And I have difficulties to understand how do you think it can be done in the Eclipse plug-ins. Processing the content sent to the ITM ports is done by the JTAG debugger software (like JLinkGDBServer or OpenOCD).

[jacek-s]

We've had issues using semihosting even for simple printf as it was too slow / it interfered with the debugged system too much - to the point where we've been losing data on interfaces that lacked hardware flow control.

As for processing data on ITM ports - I'm talking only about receiving data sent by the device. I'd assume separate ITM ports can be filtered and split on the host end (although I haven't looked too much into how it's actually implemented in the available tools).

[ilg-ul]

ITM is implemented by JLink; the debug plugin has no knowledge of this content, it only displays the JLink console.

For more details on ITM, please check the SEGGER manual. If you have suggestions to improve JLinkGDBServer, you must address them to SEGGER.

[jacek-s]

But how does the plugin actually work when it comes to getting the output from JLinkGDBServer? It has to be doing some form of parsing, as it splits the output to two separate consoles: "JlinkGDBServerCL" (memory reads/writes, register values etc.) and "Semihosting and SWV" (ITM data). That is, the data has to be somehow at least tagged as "this is not SWV data" and "this is SWV data". If so, the question is whether SWV data is further tagged with the stimulus port it was received on.

[ilg-ul]

It has to be doing some form of parsing, as it splits the output to two separate consoles

JLink does this, it provides a separate TCP port, the plug-in echoes everything without any parsing.

[jacek-s]

Okay now I get it. So if the data on the port responsible for SWO output is indeed just raw data with no tags/metadata, that is something that will need to be improved on the JLink side first. It's going to be hard though, considering there's existing tools that we don't want to break.

[ilg-ul]

You might get the original SWO data on a different port, but for the current mechanism... you got it, there is not much it can be done.

[jacek-s]

I did some research and and here's what I've gotten so far:

• On the SWO port (2332 by default) the data received does indeed seem to be tagged. It doesn't seem to be too complex - the bytes are sent always in pairs with first byte being the tag and second being the data itself. As for the tag - I haven't found any documentation regarding its format, but it's not a simple value directly. For example, sending a single ascii char "X" on ITM port 0 results in two bytes being sent: 0x01, "X", however sending the same byte on port 1 results in: 0x09, "X".
• Plugin seems to use telnet port, not SWO port. Telnet port seems to be just raw bytes as you've said, without the additional tag mentioned above. This is further confirmed by the fact that some combinations of ITM ports resulted in the tag being within printable ASCII value, which Eclipse did not print.

What I'm having problem with right now is that if I decided to use any other port in addition to the "0" one used for printf, I'd also get all that data in the plugin SWV output (as telnet port just outputs everything you give it). That means that if I wanted to write my own tool to connect to the SWO port by myself and consume data on ports other than "0" (or whatever is configured to be used for printf), it would make SWV console unreadable in Eclipse, as it'd be interleaved printf and "other" data in one window. That in turn would mean that I'd have to roll full support for logging on all ports and output that to a separate window in my own tool, while abandoning SWV console in Eclipse which would be unreadable at that point.

Having said that, it doesn't seem to be too difficult to parse SWO port in JlinkGDBServerCL. Read always pairs of bytes -> filter based on first byte -> output second if passed filtering. Even if that was used only to filter out printf data while ignoring data appearing on other ports, that would be a great improvement to me, as I'd be able to write my own tools utilizing those additional ports while interfering with what the plugin outputs to SWV console.

[ilg-ul]

it doesn't seem to be too difficult to parse SWO port

fell free to write your own parsers. check SEGGER software first, since they might already provide some support.

if you do not need the Eclipse semihosting console, you can ignore it, or disable it completely.

[TommyMurphyTM1234]

Isn't this what you want here?

https://www.segger.com/products/debug-probes/j-link/tools/j-link-swo-viewer/

Would this link also be of any use? It's from 2016 so I'm not sure if it's still all relevant?

https://mcuoneclipse.com/2016/10/17/tutorial-using-single-wire-output-swo-with-arm-cortex-m-and-eclipse/

[jacek-s]

@TM1234 I know about this tool but that's not exactly what I need. What I'd prefer to have would be existing SWO console work as it does currently (which I need as it's quite convenient) with it simply not displaying data output on ITM ports other than specified. That is for example, SWO console displays trace output on port 0 and nothing else, while I with my own parsers consume data on ports other than 0.

In current implementation, SWO console will display everything, including ports other than 0.

[ilg-ul]

SWO console will display everything, including ports other than 0.

if you know what commands to issue to JlinkGDBServerCL to filter on ports, add them to the plug-in graphical configuration.

the plug-in does no magic, it passes the commands to JlinkGDBServerCL and displays the console; basically you can configure everything SEGGER allows you to configure.

if you discover any problems in how the plug-in communicates with SEGGER, report them here, but this does not seem such a problem.