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

[support]

Hi,

This looks like an issue with the Qt build scripts and not VisualGDB. Please refer to the Qt CMake documentation and/or Qt forums for further help with this.

That said, if you can successfully build the project manually (via the command line), but it does not work with VisualGDB, please try comparing the build command lines as shown here. If you can confirm that the command line used by VisualGDB is specifying something incorrectly, we should be able to fix it.

[support]

Thanks for letting us know. We do regularly test VisualGDB on multi-monitor configurations and have not managed to trigger the issue. Most likely, it is caused by a combination of a specific display driver and resolution settings. As the issue does not affect other users, we will not be able to allocate sufficient resources to do a full investigation at this point. However, we will keep a note of this and will double-check the multi-display functionality next time we redesign the VisualGDB Project Properties GUI.

If anyone else encounters a similar issue, please feel free to post here and we will try to re-prioritize this.

[Author]

Posts