Forum Replies Created
-
Posts
-
Please note that VisualGDB is a productivity tool for software developers. It can make developers more productive by providing convenient GUI for common time-consuming tasks, and integrating various external tools into Visual Studio, so that they are always a few mouse clicks away.
We are able to offer VisualGDB at affordable price, because we focus on developing and supporting functionality that works the same way for multiple users, hence the development and testing effort is reused between multiple license holders.
We also receive a huge amount of inquiries asking to fix a specific broken project, help make the correct design choice, explain how a specific C++ feature works, or assist porting a library to a different platform. These inquiries require considerable effort to research and communicate the best solution. They do not scale between multiple users. I.e. helping one user solve this type of problem will not automatically help other users. It also does not help the same user avoid the same type of problem in the future. Hence, we are not able to address them within our regular support. If we included this type of help in our support, we would simply not have sufficient resources to provide it at the current license prices, or to allocate any resources to VisualGDB development.
We are happy to offer project-specific help via our consulting service per Zoom, TeamViewer or any other screen sharing service of your choice. We charge a fixed hourly rate for these sessions (billed in 1/2-hour increments), and are happy to solve any problems our users encounter. The rate includes a detailed follow-up email at the end of the session, that includes an overview of the used techniques and a summary of solved problems and future recommendations. Please contact our sales if you need more information about it.
Alternatively, please consider browsing our documentation and tutorials. Our documentation lists most VisualGDB settings, and the tutorials show how to use VisualGDB for in many real-world scenarios. Our technical support is limited to issues in VisualGDB itself, that can be reproduced from scratch per our problem reporting guidelines (i.e. do not depend on external projects that can potentially contain errors).
Thanks for the update. If the J-Link gdb stub doesn’t support SMP debugging, there is no easy way to make VisualGDB show both cores in the same session when debugging with it. That said, the gdb stub might open a separate GDB port for the second core, so you can use a second Visual Studio instance to debug it in parallel with the first one. If this works for you (and the Segger can confirm that the stub opens a second port, we can help you configure VisualGDB accordingly).
OpenOCD, indeed, would be another option. You would need to follow the steps below:
- Replace the regular J-Link USB driver with the WinUSB one (VisualGDB can do it for you if you use the USB Devices view).
- Create an OpenOCD script file that would define both cores and enable the hwthread RTOS on them (hwthread is a dummy RTOS that shows each core as a separate thread). You can also specify ThreadX instead of hwthread to have OpenOCD parse the thread state.
- Run OpenOCD with interface/jlink.cfg and your target script. OpenOCD will connect to J-Link and will allow debugging your target as usual.
If your device contains a FLASH memory, OpenOCD may not have a driver for it. However, if you are using our OpenOCD fork (installed by VisualGDB by default), you can make use of the FLASH plugin interface to easily create a FLASH programming driver.
Last time we checked, IAR ijet relied on a proprietary undocumented protocol, and hence was not supported by OpenOCD. That said, IAR might provide their own gdb server executable, that would take the place of OpenOCD, or the J-Link gdb server. If this is the case, we can gladly help you configure VisualGDB to work with it.
Hi,
You can disable Code Explorer using the “show window on startup” setting in the settings popup on top of the window.
If the problem only happens with a specific project, but not with a similar project created from scratch, it is likely caused by invalid/incompatible values in some of the original project’s settings.
The best way to find out the setting causing the problem is to compare the projects side-by-side (e.g. using KDiff3 or any other diffing tool) and try merging them step-by-step. E.g. if the diffing tool shows differences in .vcxproj, and .vgdbsettings files, you can try replacing just the .vgdbsettings file vs. just the .vcxproj file, to see which of them is causing the issue.
Once you narrow down a specific file, you can use the diffing tool to review the differences within a specific file, and merge them one half at a time, quickly pinpointing a specific setting.
We advise making multiple backups of both projects throughout the troubleshooting, as it is very easy to inadvertently break the project further by changing a slightly different setting.
If a specific setting is not working as expected (i.e. changing it on a freshly created project causes unexpected behavior), feel free to let us know and we will investigate it further.
We can also gladly do the troubleshooting for you at our consulting rate – it typically takes between 30 minutes and 1 hour to find the root cause of most similar problems. However, as this troubleshooting needs to be done for each project separately and cannot be automated, we have to charge our consulting rate to do that. Feel free to contact our sales for more information.
Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
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 project 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.
Another common cause of errors is updating to a new toolchain/BSP/SDK. Many of these components are maintained by device vendors or communities, and require minor adjustments to the project when switching to newer versions. If you have recently updated any of such components, please consider reverting back to the old version as described here. There is no need to downgrade VisualGDB itself, as it is updated separately from such components.
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.
Both 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.
Hi,
This is by design. The Quick Debug feature is supported starting from the Custom edition of VisualGDB (see the feature matrix), and will indeed not work with the Linux and Embedded editions.
As 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.
Hi,
VisualGDB stores this information in the .vgdbcmake files. This is more powerful than the regular CMake presets, as VisualGDB supports orthogonal configurations/platforms, each of them able to override project-level, build-level or debug-level settings. E.g. you can define multiple platforms for Embedded vs. Linux vs. Win32, and multiple configurations for build types.
You can find more about platforms in CMake-based projects in the Linux platform tutorial and the simulation platform tutorial.
Hi,
The Arduino package issues were caused by a slight change to the JSON schema on the Arduino side. VisualGDB 5.6R4 already handles it correctly.
Regarding the other issues, please let us know the email address associated with your license key so that we could link it to your support profile, and we will investigate them further.
Hi,
No problem, we have we reproduced and fixed the issue. Please try this build: VisualGDB-5.6.104.4533.msi
Thanks for renewing your license. The error was triggered by the settings updating logic in VisualGDB: it expected a non-empty project directory in order to save the converted register definition file there.
We have updated VisualGDB to save the converted register definition files to the directory of the original files when using Quick Debug presets. Please feel free to try this build: VisualGDB-5.6.104.4533.msi
This looks like an issue between OpenOCD and a particular ST-Link. You can try extracting the OpenOCD command line used by VisualGDB from the first line in the settings test window, running it manually, and cross-referencing the serial number command against the serial number shown in the Device Manager.
If OpenOCD fails to recognize the device despite the correct serial number, you can try using other OpenOCD builds (e.g. the ST fork).
Hi,
No problem, please renew your license via this page, and we will gladly investigate and fix it.
Hi,
It looks like an issue triggered by the project layout, and not specific to a particular SVD file.
We can gladly investigate it further if you could provide the steps we could follow on our side to reproduce the problem from scratch (including any steps necessary to create the project).
We would also kindly ask you to renew your support period here, as it has expired a while ago.
