[support]

Hi,

No problem. You can set the output directory for CMake projects via VisualGDB Project Properties -> CMake Build Settings -> Binary Directory.

You can read more about Advanced CMake projects here: https://visualgdb.com/documentation/projects/cmake/

[support]

Hi,

The “Custom Board Root Directory” corresponds to the BOARD_ROOT variable used by the NRFConnect SDK, while the “Device Tree Overlay Files” sets the DTC_OVERLAY_FILE variable. Please refer to the NRFConnect SDK documentation for detailed explanation of these variables and instructions on porting the SDK to support additional boards.

You can also try right-clicking on the existing board in Solution Explorer and select “Copy to project directory”. This will copy the current board directory from the SDK to a subdirectory under the project directory and will set BOARD_ROOT accordingly.

[support]

Thanks for renewing your license.

This message comes from the VisualGDB logic responsible for the “Step into new instance” command. It would normally set a breakpoint in main() and if you start debugging with F10 instead of F5, the program would stop once this breakpoint triggers.

Because ESP32 programs use app_main() instead of main(), this functionality won’t work by default. You can easily change the name of the function via VisualGDB Project Properties -> Advanced GDB Settings, or simply ignore the message if you are not using the “Step into new instance” command.

[support]

Hi,

We have rechecked the command dumping with ccache enabled and it did work as expected. If it doesn’t work on your side, please share a screenshot of the entire Visual Studio window showing the VisualGDB Build log from the very beginning, and we will investigate this further.

[support]

Hi,

This looks like an issue with mbed itself rather than VisualGDB. It could be caused by a buggy platform definition, incompatible settings, or unsupported combination of tools. Please try building the project manually using mbed-cli and check if the problem persists.

You can extract the command line used by VisualGDB by locating the build command line in the VisualGDB Build window (shown in cyan), right-clicking on it and selecting “Dump to a batch file”.

If the project builds manually, but doesn’t build under VisualGDB, please let us know and we will help you configure VisualGDB to match the results of the manual build.

[support]

Thanks, this looks like the .gpdsc file generated by the STM32CubeMX tool is referencing a header file that doesn’t exist. This is a bug in the STM32CubeMX tool that is likely specific to a certain device family/package. Please consider reporting it to ST. You can also work around it by simply creating the missing file.

We have also updated VisualGDB to automatically skip the missing files (VisualGDB-5.6.1.4029.msi), however it may lead to unbuildable projects that would require manual adjustment in case STM32CubeMX skips important files.

[support]

Hi,

VisualGDB Embedded Edition can be used in a CI environment, however it does not support various advanced features, such as unit tests or coverage.

We would advise reading through our TFS tutorials to get a basic understanding of the needed configuration steps.

The “no toolchain error” happens because your project references a toolchain that is not installed in the CI environment (i.e. on the same machine and under the same user account used for running VisualGDB there). You can install it manually by running VisualGDB.exe /packages or automatically via Team Settings (requires upgrading to the Custom edition).

[support]

Hi,

It looks like you have attached an incomplete configuration log. Please make sure you copy the entire log from the VisualGDB Build window (you can use the “Copy All” context menu command). It should provide more context on the error.

[support]

Hi,

It looks like your technical support has expired. Please feel free to renew your support here and we will be happy to answer your questions.

[support]

Hi,

This looks like an issue with a specific project and not VisualGDB issue. Please note that our technical support only covers issues in VisualGDB itself.

If you can get the project building outside VisualGDB, please renew your technical support here and we will help you configure VisualGDB to match the build results. If the project cannot be built manually either, simply opening it with VisualGDB won’t automatically solve the underlying issues.

[support]

Thanks for sharing the stack trace. This looks like a different error triggered by changing the “For Files Used by Multiple Projects” setting and opening a solution with 2 VisualGDB-based projects using the same file (and no non-VisualGDB projects using it). This explains why the project did not trigger the issue when we tried it with default global settings.

Please try this build, it fully resolves the issue: VisualGDB-5.6.1.4017.msi

[support]

Thanks for the detailed repro steps. We have rechecked it in 2 different environments and unfortunately could not reproduce the issue. Both following the steps you described and opening the project you attached worked as expected.

Most likely, it is indeed a VS-level bug on a specific machine (e.g. some cache or VS component is corrupt). You can try narrowing it down by creating GNU Make-based projects that do not require VisualGDB to be loaded into Visual Studio, reproducing the problem and then checking if the problem persists if you completely uninstall VisualGDB. If it still fails, the issue is definitely on the Visual Studio side.

That said, if you are planning to have any non-trivial project structure, we would advise using the new Advanced CMake Project Subsystem. It natively supports multiple targets sharing the same BSP, emulation platforms, lets VisualGDB fully control the Solution Explorer window contents, eliminating many bugs caused by Visual Studio itself.

[support]

Sorry, the VisualGDB unit test functionality only supports the following devices:

• ARM-Cortex devices capable of background memory reads, such as Cortex-M0, M3, M4, M7.
• Any devices compatible with the ARM mbed framework when using Advanced mbed projects.
• ESP32 device when using the Advanced ESP-IDF project.

As MSP430 devices are considerably different from the ARM devices, the TinyEmbeddedTest framework will not work for them.

That said, Embedded Integration Tests do not require any special support on the device side and will work with any debuggable device architecture, including MSP430.

[support]

Hi,

This should normally not happen, so most likely the issue is triggered by some rare combination of settings.

Please try reproducing the problem from scratch (i.e. on a newly created set of projects) and share the steps we could follow to reproduce it on our side per our problem reporting guidelines.

Please make sure you also share the relevant screenshots and the call stack from the “details” view of the error window.

[support]

Hi,

According to our records, your support has expired a while ago. Please renew your support here and install the latest version of VisualGDB. If the problem persists, please let us know and we will help you get it working.

[Author]

Posts