Feature request: Cortex ITM/SWO support

[ante]

We have currently piped stdout to the Cortex ITM channels since ARM semihosting is extremly slow and the ITM channels virtually has no  performance impact at all. In order to make this work with VisualGDB we have added the following line to GDB startup commands (we use J-Link):
monitor SWO EnableTarget 168000000 3000000 0x1 0

After this we start a telnet client to GDB at port 2332.

It would be nice if this instead could be integrated to VisualGDB. The ITM channels are very easy to use. There is a ITM_SendChar() function defined in CMSIS that can be easily used to pipe stdout to ITM. And since (at least JLink) GDB can output this to a telnet server I am guessing that it should not be that hard to add a output tab that connects to port 2332 in Visual Studio.

[ante]

The syntax for the J-Link GDB command is:

monitor SWO EnableTarget <cpufreq> <swofreq> <portmask> <mode>
<cpufreq> CPU frequency in hertz, 0 = auto-detection
<swofreq> SWO frequency in hertz, 0 = auto-detect max
<portmask> A bit mask for the ITM channels to enable. (ITM_SendChar() uses channel 0)
<mode> Set to 0

[support]

Hi,

You should be able to automate this command via the Additional GDB Commands in VisualGDB Project Properties, so there is no need to change anything on our side.

BTW, VisualGDB 5.1 supports a new fast semihosting mechanism that is based on the same technology as Live Variables. It uses a circular buffer inside your program to send semihosting output without stopping the program, resulting in much higher speeds. Please consider giving it a try (you will need to enable it on the Embedded Frameworks page).

[ante]

Hi Bazis,

yes we automatically bring up PuTTY in the GDB script. But it would be very nice if it would be possible to use a Console tab in Visual Studio.

I have seen your fast semihosting solution – its very innovativ. However, our project uses a mixed environment where some developer runs Linux hence using Eclipse. For this reason we unfortunately cannot use VisualGDB fast semihosting. We have chosen ITM since it is supported by Eclipse (as well as Keil, Atollic Studio, IAR).

There are some other advantages with the ITM channel. In combination with the Cortex DWT unit it can be used to output various data automatically on certain conditions. I know you have your own profiling solution but I can just mention that you could instead let the DWT unit output the PC at a certain interval. In this case you don’t need to add any code to your project, you just configure the DWT unit.

I think some of the IDE’s mentioned above also uses the DWT+ITM to add variable trace. It is kind like a watchpoint but it does not break; instead it outputs the value that was read/written plus outputting the current PC. The latter is very useful since it would allow you to trace memory overwrite issues. If you know a certain variable is overwritten you just add this “watchpoint” to the variable and you can then, by the PC, see what parts of the code is writing to that variable. If you combined this with your disassembler you could probably even show exactly what code line generated the write.

 

[support]

Hi,

You can then use a combination of an additional startup command in VisualGDB Project Properties and the Raw Terminal (Custom and Ultimate editions only). Simply configure the terminal to connect to the port where Segger forwards the tracing output.

[ante]

Thanks Bazis – looks like the Raw Terminal is exactly what we need!

[support]

Good to know. Let me know if you need any further help.

[Rumchiller]

Since I’m playing around with the SWO-Trace channels I’m very interested in that possible solution. How do you accomplished that you could connect with telnet to the device, while VisualGDB is already connected? Indeed I am using OpenOCD.

 

Thanks in advance!

Reggie

• This reply was modified 7 years, 9 months ago by Rumchiller.

[support]

Hi,

When we tested the OpenOCD SWO support with ST-Link, we could not get it to work reliably and gave up. There are several discussions online describing the OpenOCD commands to use (e.g. this), but we cannot recommend this approach due to low reliability.

Instead we recommend using the fast semihosting that comes with VisualGDB (simply enable it on the Embedded Frameworks page). It uses a memory buffer inside your chip to stream debug messages from your firmware to VisualGDB without stopping the core. This works very fast and is 100% reliable.

[Rumchiller]

I’ve got it to work:

1. Let OpenOCD write the trace to a file ( e.g.   -c “tpiu config internal trace/output.txt uart off 168000000”), a pipe seems not to work under windows correctly.
2. Programmed a tiny C#-Console program, which is fetching the data in the file and print it right out.
3.  Added the program to a pre-debug-action in VisualGDB, so it is showing under “VisualGDB Launcher Output”.

Had to add some tweaks in my C#-Console, so the file will be deleted on startup and the console is closing itself when the “openocd.exe”-process ended.

 

But it’s annoying with the VisualGDB Launcher Output – window. I have to switch it each time from the dropdown-menu (“VisualGDB Program Output”, “VisualGDB Launcher Output”, …). It would be also very nice i could decide, if the console window is integrated in a specific window inside VisualStudio or VisualGDB or it will even open in a standalone-window.

 

EDIT: I encountered a problem. I am using the STM32F4Discovery-board and with the new added command-line-arg, the ST-Link LED is not flashing any more. However I can debug normally. Did you mentioned that as the problem?

• This reply was modified 7 years, 9 months ago by Rumchiller.
• This reply was modified 7 years, 9 months ago by Rumchiller.

[support]

Hi,

The experience we got with OpenOCD, ST-Link and SWO was that after a while the ST-Link suddenly stopped working until we physically re-plugged it. It was also very inconsistent – sometimes it worked, and the other time it did not, so it looked like some bug of the ST-Link firmware. As we tried it more than a year ago, it could have been fixed in the latest ST-Link firmware.

Regarding the launcher output, please consider putting your program to Custom Debug Steps -> Remote Console -> Use the following command to start the console. It will put your program to a separate pane in Visual Studio and will provide better experience than just the launcher output.

 

[Rumchiller]

Thanks for your response, yeah, the remote console is much better.

It would be yet nicer if i could decide where the console window would appear. I would appreciate it, if i could decide which informations will be where shown. It’s also very annoying (for me) that every time I start debugging, the “GDB-Session-Window” is staying on top, I have to click in the text-editor to hide it again. Similar to “Real-Time-Watch” and “Visual-Watch”, on each new debug session they are showing up again. Just take it as a possible feature request.

Indeed there are also lots of new gadgets and features in VisualGDB 5.2R8 which I greatly welcome. I love it.

 

Regarding ITM: I am using OpenOCD 0.9.0+ from your toolchain and working currently with the embedded ST-Link on the F4-Discovery. It works even with FreeRTOS without problems so far (except the non-blinking LED of the ST-Link).

 

Just one more thing:

When I stop debugging there opens a window (“Inline GDB Stub Output”) which says:

error during read: Bad file descriptor
dropped ‘telnet’ connection
error during read: Bad file descriptor
dropped ‘telnet’ connection

Could you help me with that?

 

PS: I am using “Visual Assist” with VisualGDB, it works really great.

[Rumchiller]

Sorry, I wanted to inform you about the ST-Link FW version, too:

V2.J27.S0

[support]

Hi,

Thanks for confirming that the SWO output works. We will consider supporting it more directly in the future versions.

The “GDB Session” window gets activated with VisualGDB wants to display details on slow commands or other long actions. If we did not explicitly activate that window, it would appear that the debug session is stuck and would be confusing. We would recommend placing the Output window and the GDB Session window in different tab groups so that they can be displayed simultaneously.

Regarding the “bad file descriptor”, we are aware of this problem but were never able to reproduce it reliably. If you could provide steps that get a 100% repro, we should be able to fix it.

[Rumchiller]

We would recommend placing the Output window and the GDB Session window in different tab groups so that they can be displayed simultaneously.

Thanks for that hint. Logical.

 

Could you provide me a few informations about that “bad file descriptor”, what is it about? Maybe I could then discover which steps could be related to that problem. Even if I create a whole new project, e.g. HAL-Blinky, that problem occurrs.

[Author]

Posts