[support]

Hi,

If you are using J-Link, it should automatically report each of the device cores as a separate hardware thread, and VisualGDB should extend this information with the software threads recovered from parsing the RTOS structures.

Could you please try running the “info threads” command in the GDB Session window? Does it show 2 threads or just one? How does it compare to the Debug->Windows->Threads window contents in Visual Studio?

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

Another common cause of errors is updating to a new toolchain/BSP/SDK. Many of these components are maintained by device vendors or communities, and require minor adjustments to the project when switching to newer versions. If you have recently updated any of such components, please consider reverting back to the old version as described here. There is no need to downgrade VisualGDB itself, as it is updated separately from such components.

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,

No problem. Please try attaching another instance of Visual Studio to the crashing one in order to obtain a call stack of the crash as shown here: https://visualgdb.com/support/callstack

Please share the obtained call stack along with a screenshot of the Help->About VisualGDB window, and we will look further into it.

[support]

Hi,

Look like you have pointed VisualGDB to the location of STM32CubeIDE instead of STM32CubeMX.

Please make sure you install STM32CubeMX and point VisualGDB to it as shown in this tutorial, and it should work out-of-the-box.

[support]

Thanks for pointing this out. Indeed, the value of ActiveSourcePath was incorrectly cached in some of the cases. We have fixed the issue in VisualGDB 5.6R3 that can be downloaded here: https://visualgdb.com/download/

[support]

Hi,

In most of the cases, our licensing server should handle this automatically by issuing a temporary activation, and later converting it to a permanent one. If not, feel free to contact our support with more details, and we will look into it.

[support]

Hi,

This is by design. The “installation prefix” setting affects the entire project by passing the CMAKE_INSTALL_PREFIX parameter to CMake via command line. It does not affect the contents of CMakeLists.txt.

[support]

No problem, please try this build: VisualGDB-5.6.102.4523.msi. We have added the following variables to it:

• ActiveSourcePath
• ActiveSourceDir
• ActiveSourceFileName

The variables will work in the custom shortcuts and throughout the debug settings for all project types. They will also work in the build settings for the projects that are built directly by VisualGDB (e.g. Advanced CMake, Arduino, ESP-IDF).

Unfortunately Visual Studio does not allow easily assigning keyboard shortcuts to dynamically defined commands (such as VisualGDB Custom Shortcuts), however you can still launch the formatting action quickly by selecting it as an active shortcut in the VisualGDB toolbar, and then clicking the “run selected shortcut” button to the right of the shortcut combo box.

[support]

Hi,

Visual Studio had basic support for embedded development since about 2018. It is comparable in functionality and usability to free tools like Eclipse and VS Code, however many non-trivial scenarios require lengthy manual setup and considerable ongoing effort to maintain a working environment. The recently added support for Azure RTOS continues the line and makes sense given the prior acquisition of ThreadX by Microsoft.

VisualGDB, on the contrary, focuses on usability, better IntelliSense engine with features like CodeJumps and Code Explorer, and also numerous advanced debugging and code analysis features. Hence, if you are looking for a basic development environment, you may find many free solutions good enough, but if you are considering non-trivial projects that could benefit from advanced tools, VisualGDB offers numerous ways of making your workflow more productive.

[support]

Hi,

We have recently added out-of-the-box Azure RTOS support to our STM32 BSP (see version 2022.01) and also updated VisualGDB to display AzureRTOS threads.

Please feel free to try this build: VisualGDB-5.6.102.4521.msi. The new functionality will also be available in the upcoming VisualGDB 5.6R3.

The visualization of RTOS primitives (mutexes, events, etc.) is not yet supported, however we will consider adding it in the future based on the popularity of AzureRTOS among our users.

If you are using Segger J-Link, it should normally present each core of a multi-core target as a separate thread, so VisualGDB would display their state out-of-the-box. If not, please let us know and we will investigate it further.

[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, please describe what you are trying to achieve vs. what you are observing using the 3-step format per our problem reporting guidelines.

Please make sure you include all relevant uncropped screenshots so that we could help you locate the relevant settings.

[support]

Good to know it works. Please try comparing the old project against the new project, and adjusting it, eliminating the differences one-by-one. Once you can pinpoint a specific difference the is causing the problem, feel free to let us know and we can point the VisualGDB setting that is affecting it.

[support]

Due to the way Visual Studio handles programming language extensions, using Clang IntelliSense automatically redirects all IntelliSense-related functionality to VisualGDB, including the formatting. There is no easy way to call the formatting logic from the regular VC++ IntelliSense while still using the Clang one.

Regarding the currently opened file, we can gladly add a new variable (e.g. $(ActiveSourcePath)) that will resolve to the currently open source file when used with custom shortcuts, if it helps you configure the formatting workaround.

[support]

Hi,

Thanks, we have confirmed that toolchains manually installed for all users (as opposed to the current user) won’t automatically appear in the VS2022 toolchain selector until you manually use the “Select a third-party toolchain” link. This is a side effect of VS2022 being a 64-bit process. Toolchains installed directly via the toolchain selector should still work.

We have fixed the issue on our side and will include the hotfix in the upcoming VisualGDB 5.6R3. As a workaround until then, please consider installing the toolchains for the current user only, or locating them manually via the dropdown in the toolchain selector.

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

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.

[Author]

Posts