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

[support]

Hi,

You can try contacting Espressif for help, or patching the ESP-IDF build scripts yourself. VisualGDB works on top of the existing scripts and cannot do it for you.

The “program from file” option programs the specified file into the bounds of the partition reported by ESP-IDF. This is done once and does not change the ESP-IDF project properties, or override the regular ESP-IDF programming logic.

[support]

Hi,

No problem, this looks like a known issue that is already fixed in our development branch. Please try this build: VisualGDB-5.6.106.4630.msi

We are maintaining our NRFConnect support. We periodically check compatibility with the latest SDK versions, update VisualGDB accordingly and are happy to offer numerous productivity features that make VisualGDB development experience better compared to VSCode.

[support]

Hi,

The exact FLASH command line is not directly under VisualGDB’s control, however we can explain what parts are involved in computing it so that you can pinpoint the correct setting:

1. ESP-IDF enumerates all KConfig files referenced by the project and stores them in the project_description.json file.
2. VisualGDB scans the KConfig files referenced there and shows the ESP-IDF-specific settings based on them.
3. When you change those settings in the GUI, VisualGDB updates the sdkconfig file.
4. When you build the project using ESP-IDF scripts, they pick up the settings from sdkconfig, and compute various command lines based on them.
5. Some command lines are saved to intermediate files such as flash_args

Modifying flash_args manually will indeed not work, since the build scripts will overwrite it. Instead you would need to find the ESP-IDF setting that controls its content and change it (either by editing sdkconfig directly, or via VisualGDB Project Properties that will let VisualGDB edit it for you). Searching ESP-IDF build scripts for flash_args or parts of the command line shown there could be a good starting point.

[support]

This is by design. Normally, VisualGDB sorts groups source files reported by CMake based on their physical directory, i.e. separating the PicoSDK Files from the rest of the files.

Once you create a virtual folder, VisualGDB assumes you want to rearrange them manually, and stops grouping them by paths, allowing you to drag them into the virtual folders of your choice. The virtual folders are completely separate from the physical folders and are stored in the .vgdbcmake file. This feature is meant for projects where many files are stored in the same directory, and the existing path-based grouping is not convenient.

If you would like to group your source files better, while relying on VisualGDB to separate the SDK sources, we would advice moving your sources to physical subdirectories, and updating the CMakeLists.txt file accordingly. VisualGDB will automatically show these subdirectories in Solution Explorer, as long as you have no virtual folders and have not disabled path-based grouping.

[support]

The exact steps to enable verbose logging depend on your project type. You can find them for most of the project types in our documentation.

If it doesn’t help, please let us know the exact project type you are using (i.e. what was selected on every step of the wizard) and we will point you to the relevant documentation.

[support]

Hi,

This is to be expected, as our tutorial is for the STM32F407VG device. Copying device-specific code into a project targeting a different device will indeed most likely result in various errors.

That said, different STM32 families use fairly similar APIs, so porting the code between them should be fairly easy, as long as you understand the differences between them. Looking through ST documentation/samples could be a good starting point.

[Author]

Posts