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

[support]

Thanks, this looks like a slightly different variation of the problem coming from the disassembly window. Please try this build: VisualGDB-5.5.104.3990.msi. If the problem persists, please attach the updated log and screenshots.

Also, in case anyone else is experiencing this, below is an explanation why it’s taking so long to pinpoint.

A recent update to Visual Studio changed the logic used by the Call Stack window so that it will sometimes try to re-query its contents while VisualGDB is already running another GDB command. This happens very rarely and intermittently, and almost never happens when a debugger is attached to the VS itself, so we have initially incorrectly concluded that VS was losing the frames reported by VisualGDB (in reality, it was sometimes re-querying them in an unsupported way that never happened with a debugger attached). We have initially updated VisualGDB to prevent VS from re-querying the frames by temporarily suspending background job processing in the main thread until the main GDB command would be completed, but it did not solve all the instances of the problem. The latest fix introduces caching instead. Now if Visual Studio queries the call stack in an unexpected way, VisualGDB will simply return the last known version of it. This may still not be a 100% solution in case VS submits a stack frame request in an unsupported context before submitting it in a regular context. As the problem is extremely intermittent and rare, it’s hard to predict whether it’s likely or not. If this happens, we will consider other workarounds as well.

[support]

Hi,

There is no advantage on building the code for Raspberry Pi Pico on a regular Raspberry Pi and it is not practical to build the code on the Pico itself. Hence VisualGDB will build the code directly on Windows using a cross-toolchain. You will be able to use a regular Raspberry Pi as a debug probe if you prefer this option.

[Author]

Posts