[support]

Hi,

Installing the same (latest) version of VisualGDB on all machines should normally help. You can double-check the installed version via Help->About VisualGDB.

[support]

Hi,

The build error looks like something on your computer is interfering with low-level operations. It could be malware, buggy antivirus software, RAM malfunction, but it doesn’t look like something VisualGDB would directly control.

Regarding unit tests, please try following this tutorial. It shows all the necessary steps to run unit tests within Windows applications.

[support]

Hi

Currently, 64-bit Raspberry Pi images appear more experimental than mainstream (e.g. not shown directly near the 32-bit images on the website), so we do not have any plans of releasing compatible cross-toolchains until we see this change. That said, if you are OK covering the toolchain building costs directly, feel free to contact our support with more details, and we can gladly give you a quote (we might be able to reduce/waive the fee if your company holds multiple VisualGDB licenses).

[support]

Hi,

Most likely, the problem was triggered by changing some setting in the old project, or hardcoding some parameter in it in a way that only worked with a specific version.

As you now have 2 nearly identical projects that work differently, you can always try comparing them file-by-file (and editing them to eliminate the differences one-by-one), to see what exact setting was causing this.

[support]

Hi,

If hovering over the variables causes the gdb session to crash, it is likely caused by partial incompatibility between the debug information used in your settings, and the specific version of gdb. You can try changing both of them as shown below:

• The debug information format (DWARF-2/DWARF-4/etc) can be adjusted via the VS project properties (MSBuild) or target properties (CMake), under C/C++ -> General.
• You can try using other versions of gdb by downloading older ARM toolchains.

The -stack-list-frames command usually takes too long if gdb enters and infinite loop while trying to unwind the stack. You can constrain it by setting a hard limit on the number of unwound frames by adding the set backtrace limit command to additional GDB commands.

The -break-insert command delays could be due to large debugging symbols, or if the breakpoint got resolved to multiple physical addresses (e.g. a function inlined from 10 different places). You can recheck the physical addresses in the output from -break-insert, and also try running “set debug remote 1” before setting the breakpoints, so that gdb will display its communication to the gdb stub. If -break-insert does not result in multiple small packets sent to the stub, the delay comes from gdb trying to parse the debug symbols. This delay can be reduced by stripping the debug information from the source files unlikely to be debugged (see this tutorial) or by using gdb index files.

If you can confirm that manually configuring the index files does result in a consistent speedup, please feel free to share more details, and we will consider adding a setting for managing them automatically.

[support]

Thanks for confirming this. Selecting the first option should normally indeed target both cores. If the second thread does not appear, you might be using an older version of the J-Link gdb stub, or missing some additional parameters.

We would advise double-checking this with Segger support – simply forward them the J-Link gdb stub command line shown in the VisualGDB Output window, along with your device name and the Segger software version, and they should be able to suggest a way to configure the stub to show each core as a separate thread.

[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. You can use the timing view in the GDB Session window to quickly find out which commands are taking the most time.

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

[Author]

Posts