Sysprogs forums › Forums › VisualGDB › Segger RTT & SWO tracing support in future?
- This topic has 5 replies, 3 voices, and was last updated 2 years, 10 months ago by support.
-
AuthorPosts
-
June 5, 2020 at 15:22 #28342kurta999Participant
Hi,
Is segger RTT tracing support and SWO tracing is planned to be added to Visual GDB in future for ARM?
Segger RTT is just a simple telnet client. AFAIK openocd doesn’t support SWO but J-Link one supports it.
https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/
June 5, 2020 at 15:45 #28344supportKeymasterHi,
VisualGDB actually provides its own mechanism for fast tracing – the advanced semihosting framework. You can reference it via VisualGDB Project Properties -> Embedded Frameworks and then use the regular printf()-like functions to output data. See this tutorial for a detailed example.
If you would like to specifically use SWO, you can configure it manually as shown here (use VisualGDB Project Properties -> Additional GDB Commands) and then use VisualGDB’s raw terminal to connect to the port where J-Link outputs the SWO data.
January 28, 2022 at 08:38 #32111s.voulazParticipant+1 for RTT client support (really useful for embedded projects)
It that planned anyhow?
January 28, 2022 at 08:44 #32113supportKeymasterAs the VisualGDB semihosting/profiling framework provides similar functionality to RTT, and is not limited to specific debug probes, we do not have any plans of replacing it with RTT. On the contrary, we have plans of extending it to support more fine-grain tracing functionality.
January 28, 2022 at 09:26 #32116s.voulazParticipantOk, got it. I was thinking about existing projects, especially hard-realtime designs, on which it is not possible to replace the debug framework – any semihosting is way more intrusive and orders of magnitude slower. But yes, that’s probably something in charge of Segger as a plugin for VS (not VSCode, that already supports it).
Talking about Segger’s jlink, however, I am experimenting an apparently weird behavior of the Quick Debug setup. In order to debug an existing CMake project, I have to check “The debugged device is not listed. Configure the debug method manually.” and specify all the debug connection details for J-link. If instead I select the device (MXIMRT1061xxxxA) from the list, then “Debug using:” shows “No compatible USB device found” – although the package Segger J-Link 5.9 is installed. Is this by design?
January 28, 2022 at 09:28 #32117supportKeymasterBoth Segger RTT and the fast semihosting framework rely on the same underlying principles (ring buffer in the target memory accessed without stopping the CPU), so there should not be any noticeable performance difference between them, as long as you are using the optimized release build. The bottleneck in both cases would be the JTAG/SWD bandwidth when doing background memory reads.
Regarding Quick Debug, according to our records, you are using the VisualGDB Embedded Edition that does not support Quick Debug. In order to use Quick Debug, please upgrade your key to the Custom edition or higher here: https://sysprogs.com/splm/mykey.
If it still doesn’t work, please provide complete and detailed steps to reproduce the issue as described below:
- The steps should begin with launching Visual Studio. They should include every step necessary to create the quick debug preset from scratch and reproduce the issue.
- Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
- The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.
You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.
Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.
You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.
-
AuthorPosts
- You must be logged in to reply to this topic.