[support]

It generally depends on your project type. Normally, if you have VisualGDB and the toolchains/BSPs installed on the build server (same user account as used by Jenkins), you do not need to specify them manually.

You can find several tutorials showing how to use VisualGDB with CI/CD systems here: https://visualgdb.com/w/tutorials/tag/tfs/

[support]

Sorry for the confusion. The NRFConnect projects are not based on MSBuild. They use a completely different mechanism for loading and building, so the MSBuild executable will not recognize them. You can still build them by running devenv.exe /build if you prefer to use the same mechanism for all project types.

That said, if you have VisualGDB installed on that machine, it is easier to build the projects by running VisualGDB directly:

VisualGDB.exe /build <file.vgdbproj>

 

[support]

Thanks for confirming this. Please try the following build, it uses forward slashes for DTC_OVERLAY_FILE: VisualGDB-5.6.104.4539.msi

[support]

Hi,

This happens because the build system does not have VisualGDB installed, so it cannot load the .vgdbproj files.

That said, NRFConnect projects are built directly by CMake with the NRFConnect build scripts. VisualGDB simply runs the build tools and interprets the results. Hence, you can build the project on your build server by manually running CMake and Ninja with the same command lines as used by VisualGDB (you may need to adjust some absolute paths).

Please refer to the following page for a detailed explanation how to CMake-based build projects outside VisualGDB: https://visualgdb.com/documentation/projects/cmake/#troubleshooting

[support]

The first option should work. You can switch the filter from gdb.exe to toolchain.xml in the bottom right corner of the “open file” dialog.

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

[Author]

Posts