[support]

You can dump the command lines used by VisualGDB by right-clicking on the cyan lines in the configuration log (first line on your screenshot) as shown in our documentation. Please ensure you dump them and follow the troubleshooting instructions from our first reply. If you do not wish to do it, we can add this issue to the backlog, however we would need to wait for other users to confirm it before committing any resources to further investigation.

[support]

Thanks for renewing your support. The logic used by VisualGDB to automatically find installed toolchains indeed only counts the GCC/GDB versions, since the revision number (e.g. R2) for all regular toolchains refers to bugfix releases the fully supersede the older ones.

ESP32 toolchains are an exception from this – Espressif often releases minor toolchain patches that keep the same GCC/GDB version numbers, but change the functionality in subtle ways, affecting compatibility with different ESP-IDF versions.

That said, the workaround for this is very straight-forward: simply select “locate the toolchain manually” in the toolchain selector drop-down, and point VisualGDB to the corresponding toolchain.xml file. It will allow having multiple toolchains with the same version, only differing in the revision number.

Regarding the 8.4.0/8.1.0/r1 toolchain, due to the large size of the ESP32 toolchains, we usually remove the versions that get superseded by the newer releases (i.e. have the same ESP-IDF versions as the previous one, and only introduce bugfixes) and the versions older than a couple of years. You can find the full list of available toolchains here: https://gnutoolchains.com/esp32/. If you are planning to use a certain toolchain version for longer than a couple of years, we strongly advise making backups of the installer on your side.

[support]

Sorry, this looks like an issue with your board, and not something specific to VisualGDB.

[support]

Hi,

Debugging CMake files requires building our fork of CMake and will not work with the regular builds. Please refer to this page for more details.

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[support]

The window should normally activate automatically as per tutorial and does not depend on the Visual Studio version.

In general, some VisualGDB settings look alike and it’s very easy to inadvertently break things by selecting an incompatible combination of settings. If you are new to VisualGDB, we advise following the tutorials as close as possible. If VisualGDB doesn’t work the way you expect, please provide the repro steps including all relevant screenshots as suggested earlier, and we will try to point out what could be causing the issue.

Due to the sheer amount of different project types and configurations, we will not be able to suggest anything meaningful without seeing the full context of the issue.

[support]

Hi All,

Build issues like this one are often caused by subtle differences in the configuration (spaces in paths, environment, SDK versions), so in order to troubleshoot them efficiently we always ask our users to reduce them to a specific parameter controlled by VisualGDB, such as the CMake command line. Based on your screenshot, everything works as expected – the first line of the configuration log is an exportable command line shown in cyan, as shown in the documentation page.  The build log is not shown yet because the project configuration has not succeeded. Please follow our instructions from our previous reply in order to capture and edit the build command. Once you can confirm that adjusting the command line solves the issues, please share both batch files, and we will update VisualGDB to adjust the command line accordingly.

[support]

Hi,

If VisualGDB is not working as per tutorial, please provide the 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.

[support]

Good to know it works. In general, the “empty project” option simply strips all sources from original project template. It cannot automatically determine which of these sources would be needed in each specific scenario, so it may indeed involve some trial-and-error to figure that out. Having a working project based on the full template as a comparison could be a good reference point.

[support]

Thanks, we have reproduced the issue. It is triggered by selecting “Empty project” on the Sample Selection page of the wizard. This option assumes that you are familiar with the underlying SDK and can add all the necessary files manually.

Please try selecting “Default project” instead – it will import a sample project from the SDK itself, that should include all the necessary files.

That said, with this specified SDK, you will need to manually reference the AtmelStart framework via VisualGDB Project Properties -> Embedded Frameworks. We will address this in the next VisualGDB version; until then, please reference the framework manually after creating a project.

[support]

Thanks for the detailed repro steps. The issue was triggered by adding folders to first-level Solution Explorer nodes with source/header filters disabled. As it is a relatively rare scenario, it makes sense why it wasn’t caught by our tests or reported by anyone else.

We have fixed the issue in the following build (and also added a checkbox for creating an extra node for the imported folder itself): VisualGDB-5.6.104.4538.msi

[support]

Hi,

This is handled directly by CMake, rather than VisualGDB. Feel free to browse through CMake source code to see if there is a way to modify this behavior.

[support]

Hi,

Good to know it works.

Regarding the activation, you can always reenter your key via Help->About VisualGDB in order to update its state.

[support]

Thanks for the detailed repro steps. It looks like you are targeting a device from an Atmel START SDK that you have previously imported into VisualGDB. This issue could be a bug of this specific SDK, or a glitch in our importing logic.

Please try deleting the imported SDK (its location is shown at the bottom of the Device Selection page in the wizard) and importing it again. If the problem persists, please upload original SDK archive in a file sharing service and post a link here, so that we could recheck if our importing logic is handling it correctly.

[support]

Thanks for updating your profile. Unfortunately, we are not able to review specific projects for errors, however we can help you get the command dumping to work.

If you could attach a screenshot of the entire Visual Studio window showing the VisualGDB Build window with the missing commands, we can help you understand why they are missing.

[Author]

Posts