[support]

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 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.

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).

[support]

​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 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.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided, as VisualGDB supports many different project types and configurations.
In order for us to provide any help with this, we need to know the exact configuration you have.
Please provide complete and detailed steps showing how you configure your project:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch.
2. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages involved in creating the project.
3. Please describe the exact behavior you would like to achieve (e.g. some items appear in Solution Explorer in certain order) based on the previously provided steps, so that we can point out the relevant settings.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines.

It also looks like your support period has expired, so we would kindly ask you to renew it here: https://sysprogs.com/splm/mykey

[support]

Hi,

We have just retested it with the ESP32-S3-BOX and it worked just fine. Please make sure you actually install the WinUSB driver for the “USB Composite device”  as VisualGDB suggests (you need to select “USB Devices” in the “Debug Using” field for VisualGDB to check the drivers).

The default driver layout (separate serial port & debug nodes) appears to be incompatible with the current version of OpenOCD.

[support]

This looks like an error coming from the ESP-IDF build system and not something specific to VisualGDB. Please refer to the ESP-IDF documentation for more details on it.

If you can build the same project outside VisualGDB, but not with VisualGDB, please follow the troubleshooting instructions here to get it working.

[support]

Hi,

Most likely, some build parameters (e.g. optimizations, libraries, etc.) are different. Since both VisualGDB and STM32CubeIDE use the same compiler (gcc), you can get them to produce nearly identical output (the only difference will be the order of symbols in the image), however it will require comparing build command lines side-by-side. We have a detailed tutorial showing how to do it for another compiler here.

Another option would be to use the Embedded Memory Explorer to quickly compare the footprints of 2 builds to see if there is any obvious difference (e.g. some symbols only present in one file, or every symbol being proportionally larger, implying different optimization).

[support]

Sorry, VisualGDB 5.3 is 5 years old, is no longer maintained and does not support the new package list format. Please consider updating to the latest VisualGDB 5.6.

[support]

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:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. 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.
3. 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.

[support]

Hi,

No problem, please let us know the email address associated with your license key, so that we could check your support status, and we will be happy to help you.

[support]

Hi,

This looks like an issue in OpenOCD rather than something VisualGDB-specific. You can try building OpenOCD from sources by following this tutorial, and then step through it to understand what is going on.

Another option would be to switch to Segger J-Link. It comes with its own fully supported replacement to OpenOCD, that generally works better for many devices.

If the Atmel IDE works well, you can also try using Process Monitor to to see if uses gdb and whether it launches its own gdb stub similar to OpenOCD. If both are true, and you can run the same stub manually (and connect GDB to it), you can configure VisualGDB to launch it as well by selecting the “Custom GDB stub” mode in VisualGDB Project Properties -> Debug Settings. Note that the last option is something to do at your own risk, as it involves running undocumented Atmel tools.

[support]

Hi,

This is actually shown right after the instructions to dump the command line in the same troubleshooting page. You will likely need to set it for both CMake and Make/Ninja commands.

That said, it looks like your manual setup is using a different toolchain (esp-2022r1-RC1-11.2.0), that would explain the different behavior.

The best way to integrate it would be to:

1. Create a backup of the c:\SysGCC directory
2. Delete the old ESP32 compiler directory (E:\sysgcc\esp32\tools\xtensa-esp32-elf\esp-2021r2-patch3) and copy the 2022r1 version under E:\sysgcc\esp32\tools\xtensa-esp32-elf.
3. Edit toolchain.xml and bsp.xml, replacing xtensa-esp32-elf/esp-2021r2-patch3 with xtensa-esp32-elf/esp-2022r1-RC1-11.2.0 where appropriate (please use extra caution, since ESP32-S2/C3 targets use separate toolchains in their own directories).
4. Reopen the solution.

Again, this is something to do at your own risk. We will do all these steps, retest everything and publish a ready-to-use package once Espressif deems them stable enough for a general release. We intentionally do not do this for pre-release versions, as they tend to be much less reliable and often change in various subtle ways before the final release.

 

[support]

Thanks, we have rechecked that Atmel SAM BSP, and confirmed that the default sample was using the incorrect syntax (that was initially derived from the SAM0 sample).

We have fixed the issue here and released an updated BSP resolving it. You can update to it via VisualGDB Package Manager.

[support]

Sure, you can always follow the troubleshooting instructions from the same documentation page you mentioned. They show how to narrow the problem down to specific command lines, so you can compare and adjust them outside VisualGDB.

[support]

Hi,

We usually test VisualGDB with the new ESP-IDF versions once they are officially released by Espressif (i.e. mentioned as a stable release on the releases page and distributed via the Espressif’s installer). It typically takes a couple of weeks after the official release from Espressif for us to retest everything and update VisualGDB.

If the release is not mentioned there, it has likely not been fully tested by Espressif yet, may not be usable yet, and may change considerably before the final release. If you would like to get a timeframe of the official ESP-IDF v5 release, please contact Espressif.

[support]

Hi,

The support for a specific language standard (e.g. C++20) comes from the gcc version included in your toolchain. VisualGDB works just fine with it, as long as your toolchain supports it.

The wizard indeed shows language standards up to C++17, but you can always change the standard to C++20 via project properties, once you have selected a toolchain compatible with it.

For CMake projects, you can also just set the language standard directly by editing the CMakeLists.txt file. VisualGDB will automatically pick it up once you reload the project.

[Author]

Posts