[support]

Yes, installing VisualKernel inside a QEMU Windows VM running in a Linux machine very likely interferes with the target connection.

Such setup will require non-trivial QEMU configuration to ensure that the debug transport you would like to use works reliably between the Windows VM and the target. It is something for you figure out – VisualKernel cannot automatically do it from within a VM. In general, please make sure you can manually debug the target kernel by running gdb on the Windows machine manually (without loading the symbols for the kernel/modules). If not, please resolve your target communication issues before attempting to use VisualKernel.

Also, the “Cannot complete the smart archive without closing the ‘source’ area” error could be shown incorrectly if a different error prevents VisualKernel from downloading the kernel sources. We have fixed it internally: VisualKernel will display the correct error message starting from the next build. In Beta 1, you can find out the actual error via View->Other Windows->VisualKernel Diagnostics Console.

[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, VisualKernel 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/VisualKernel 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 VisualKernel 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/VisualKernel 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,

The “fast clock” refers to the entire device rather than the profiler. E.g. using the HSE + PLL instead of the slower HSI clock. You can find more details about the STM32 clocks in the STM32 HAL documentation, device datasheets and mbed documentation.

That said, the instrumenting slowdown of 23x indicates that you have instrumented some very small functions that invoked frequently. We would advise finding out the most frequently executed functions via the profiler view, and then specifically excluding them from instrumentation in the “Start Profiling Session” window. This will greatly reduce the overhead, while still giving a good picture of the performance of various parts of your program.

[support]

Hi,

It looks like the MSBuild logic for the project has not been initialized properly. Please double-check whether you can create/edit a new project of the similar type. If yes, please try comparing the failing project file against the newly created project file.

If the new project doesn’t work either, please let us know and we will help you narrow this down further.

[support]

Hi,

This looks like a general network configuration error and not something specific to VisualGDB. Please make sure you can connect to the same VM using PuTTY or any other SSH client. Once this works, feel free to share the settings that worked and we will help you configure VisualGDB to connect to the same target.

[support]

Hi,

This is the ESP-IDF path, not the toolchain path. If you would like to change the toolchain path, please refer to the instructions from our previous reply.

The ESP-IDF always needs to be installed in a subdirectory under the toolchain directory and cannot be referenced via a relative path. If you would like to check it into source control, please consider putting it into a separate git repository and checking it out under the toolchain directory.

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

[Author]

Posts