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

The regular OpenOCD GUI is indeed optimized for running OpenOCD locally – it can automatically find the supported JTAG/SWD probes, install drivers, locate device scripts, etc.

If you would like to run OpenOCD remotely, please try selecting the “Full-custom” debug method instead of OpenOCD. It allows specifying arbitrary target connection commands, and will not attempt to do anything beyond what is explicitly configured.

[support]

Hi,

Based on the log, it looks like the connection has been established.

Could you please describe a bit more what is happening: does Visual Studio show that a breakpoint has been set (i.e. shows it as a solid circle)? What happens if you use the Debug->Break All command to pause the target?

Please also try attaching a gdb log  – it will show what is going on.

[support]

Hi,

Sorry about that. We were doing some resource-related refactoring in our development branch, and it resulted in a few broken references in the daily VisualGDB builds. We have fixed it in the latest build: VisualGDB-5.6.105.4588.msi

[support]

Sorry, this is not something VisualGDB directly controls. All we can suggest is to try contacting the board manufacturer or the debug probe manufacturer.

[support]

Hi,

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, as many issues are triggered by specific combination of project/target settings.
2. The steps should include the expected/observed behavior, so that we could follow them on our side and compare the outcome.

[support]

Hi,

Thanks for checking the debug output. Indeed, the stripping logic was not working with the custom imported toolchains, that internally use the $(ToolchainDir) syntax. We have fixed it in the following build: VisualGDB-5.6.105.4579.msi

[support]

Hi,

The “Strip debug symbols during deployment” option simply runs the toolchain’s objcopy executable on the primary output of each project before deploying it:

...-objcopy.exe --strip-debug <ELF file> <ELF file>-stripped

The <ELF file>-stripped file is then deployed to the target and deleted locally.

You can double-check what is going on by checking View->Other Windows->VisualGDB Diagnostics Console. You can also try running your toolchain’s objcopy executable (on the build machine) on the deployed ELF file to see if it manages to strip the symbols.

[support]

Hi,

The only fully tested & supported way to do this would be to use the Embedded CMake project subsystem (see this tutorial). You might be able to get it working with MSBuild as shown below:

1. Follow the CMake tutorial to get a reference test project that builds and runs without hardware.
2. Create a regular Win32 MSBuild executable. Manually add the unit test framework to it via VisualGDB Project Properties. Adjust the project until it builds and runs as well, using #1 for reference.
3. Follow the MSBuild Platform tutorial to merge the settings from #2 into your main project. For MSBuild projects, VisualGDB only cares about the currently selected platform/configuration, so if you manually copy all settings (including the references to .vgdbsettings files) between projects, it will copy the related behavior regardless of what is defined in other configurations/platforms.

That said, this setup was never tested, and may trigger weird bugs. Proceed at your own risk only if you are comfortable patching MSBuild files and troubleshooting possible errors caused by it.

[support]

Thanks for renewing your license.

Normally, GDB would automatically search for libraries with symbols in its sysroot directory on the Windows machine (use the “show sysroot” command to find it out). However, you can override this behavior by issuing the set solib-search-path command via the GDB Session window, or adding it to VisualGDB Project Properties -> Additional GDB Commands.

Note that the library on the Windows machine must match the library loaded on the target, otherwise gdb would use incorrect addresses for most symbols, resulting in unpredictable behavior.

[support]

Sorry, our system still shows the old license expiration date. If you have placed a renewal order, please contact our sales with the order details.

[support]

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[support]

Hi,

The Custom Build Steps page is available on VisualGDB Custom edition or higher. If you are using a lower edition, you can always upgrade your key here: https://sysprogs.com/splm/mykey

[support]

Hi,

This happens because the copy command is not a separate executable, but is rather a built-in command of cmd.exe. Hence, you can launch it as follows:

File name: cmd.exe
Arguments: /c copy /b <…>

[support]

Hi,

It looks like a bug coming from the toolchain or gdb executable. You can double-check the gdb replies to VisualGDB’s commands in the GDB Session window or in the GDB log. If the error message is present there, the issue is coming from GDB and is not controlled by VisualGDB.

If you wish, we can build a debug version of gdb, find the root cause of the issue, and patch it for you, however as it is not an issue of VisualGDB itself, it would be subject to our consulting rate.

[Author]

Posts