[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide 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.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

Hi,

If you would like to generate the XML reports using the GoogleTest logic, you would to specify any additional environment variables via VisualGDB Project Properties -> Debug Settings and add custom actions for downloading the test results file (if the test runs on a remote machine).

That said, VisualGDB has its own mechanism for creating test reports. You can run VisualGDB.exe /runtests /output:xxx (or /vsoutput:xxx) to run tests from command line and generate a test report either in the VisualGDB format, or the MSTest format. See this tutorial for more details.

[support]

Hi,

Based on the screenshots you provided, the build also fails. So it looks like a corrupt build environment and not a VisualGDB IntelliSense issue.

[support]

Hi,

This happens because you are using the latest packages with an old version of VisualGDB. Please update to the latest VisualGDB 5.6 and it should work out-of-the-box.

[support]

Hi,

This might be related to the package load key mechanism. Please try installing the VS2008 SDK. It will automatically disable the package load key verification and will allow the VisualGDB package to load properly.

[support]

Hi,

Sure, you can download various packages manually here and install them via Tools->VisualGDB->Manage VisualGDB Packages.

BTW, if your corporate network uses a proxy server and denies direct connections, you can configure VisualGDB accordingly via Tools->Options->VisualGDB->General->Other->Proxy Server.

[support]

Hi,

The version of CMake installed by VisualGDB is 100% compatible with the regular CMake. The only differences introduced by it are related to accurate reporting of the code model (e.g. various statements affecting each target’s CFLAGS) and to debugging (stepping through CMakeLists.txt files).

For projects built locally VisualGDB always tries to use our CMake fork, as it makes the settings editing GUI more accurate (VisualGDB can better locate and edit existing statements when you change target settings via target properties). Either way, we have added a setting to disable this behavior to the following build: VisualGDB-5.6.106.4647.msi. The new setting is located under Tools->Options->VisualGDB->CMake->Use pre-built CMake for Local Builds.

[support]

Update: we have just rechecked VisualGDB profiling with the latest mbed 6.16 and it worked just fine. We have updated the tutorial showing how to patch the mbed source to facilitate profiling.

If it still doesn’t work for you, please follow the instructions in our previous reply to carefully document every step you take when creating the project, and we will gladly point out the possible cause of the problem.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide 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]

Hi,

VisualGDB references toolchains using unique IDs and versions:

• Each project file contains a ToolchainID element with the toolchain ID and version
• VisualGDB matches it against a list of known toolchains on this computer (see this page) and automatically loads the correct toolchain

This mechanism allows having different toolchain locations on different machines while sharing the same project file between all users.

If you would like to check in your toolchain into the your repo, you can simply move the toolchain there, and then import it into VisualGDB on each computer (click the “locate existing toolchain” link in the toolchain selector and point it to the toolchain.xml file). VisualGDB will then automatically locate it using the usual ToolchainID reference.

You can also use the Team Settings to automatically install the same toolchain on multiple computers.

[support]

Hi,

The ESP32 projects (and other Advanced CMake projects) use a different structure of settings compared to the regular MSBuild/Make projects.

Please see this page for a detailed overview.

[support]

Hi,

According to our records, your license does not have an active technical support. If you believe it is a mistake, please contact our support via the contact form.

[support]

Hi,

The exact names and structure of the IRQ handlers slightly varies between different mbed versions.

In general, the thread_switch_helper callback is supposed to be called just before the mbed runtime switches the context to another thread, so the VisualGDB profiler could handle this event and update its internal structures accordingly.

If the version you are using does not have the SVC_ContextSwitch call, please try locating the logic responsible for loading the stack pointer (similar to SVC_ContextRestore on the screenshot in our profiling tutorial) and inserting the call to thread_switch_helper just before it.

Edit: we have just retested the VisualGDB profiling with the latest mbed release and updated the tutorial. As of mbed 6.16, the call to thread_switch_helper goes right after the SVC_ContextRestore label and needs to save/restore the LR register as well as shown in the updated tutorial.

[support]

Hi,

We have just rechecked the switching between the debug and release configurations and it worked just fine.

Most likely, you have changed some project settings to the values preventing VisualGDB from loading it.

Please try creating a new project from scratch and check if the problem persists. If not, please try comparing the settings between the 2 projects and eliminating the differences one-by-one.

[support]

Hi,

For CMake projects, the debugged executable path is automatically derived from the actual project structure. If you would like to debug arbitrary executables, we would advise using Quick Debug instead.

If you would like to have multiple debug configurations, you can try using the configuration/platform manager. Simply add a CMake-level variable in the configuration settings, and then check it on the CMake statement level (e.g. using the ${} syntax or in conditional statements) to produce different executables in different configurations.

VisualGDB will automatically pick up the correct executable based on the active platform.

If this is not what you are looking for, please let us know more what you are trying to accomplish, and we will try to suggest a better solution.

[Author]

Posts