[support]

Hi,

VisualGDB 5.4 has been released over 2 years ago and is no longer maintained. In order to get the latest updates, we recommend updating to VisualGDB 5.6.

[support]

Hi,

This is something to check in the MSP430 GCC documentation. E.g. you may need to specify it to both compiler and linker, or to specify some additional settings.

You can also verify the exact flags passed by VisualGDB to GCC by reviewing the RSP files (MSBuild) or adding “-v” to Ninja  command line (CMake).

[support]

Hi,

This looks like a generic programming issue and not something VisualGDB-specific. If you believe VisualGDB is not working as expected, please try reproducing the problem from scratch (on a cleanly created empty project) and let us know the steps to reproduce it per our problem reporting guidelines.

If the problem only happens on a specific project, please try comparing this project to a cleanly created project until you can pinpoint a specific setting that is causing this. If you believe this setting is not working as expected, please let us know more and we will investigate it further.

[support]

Hi,

This is a known issue that was fixed in VisualGDB 5.6 Beta 5. Please try updating to that version.

[support]

Thanks for letting us know. Intermittent problems like this one are often caused by unstable clocks, power issues, or wiring. In case you encounter it again, please try using a different board.

[support]

No problem, please see the following page for details: https://visualgdb.com/tutorials/arm/tests/resources/

[support]

Hi,

This likely indicates a memory corruption. This error means that the most significant bit of the s_FastSemihostingState.WriteOffset variable (0x80000000) is set, which is a special value reserved for the resource manager API. If you are not using the resource manager, something likely overwrites WriteOffset with an invalid value.

Memory corruption problems could be tough to pinpoint. The easiest way to handle it would be to revert to the last version that worked via your source control (or re-create the project from scratch, if it is trivial). You can also try setting a breakpoint in WriteRawFastSemihostingData() and observing how it changes s_FastSemihostingState.WriteOffset (it’s a simple ring buffer that is written by the firmware and read by VisualGDB), although it could take some time to find the root cause this way.

[support]

Hi,

Based on the screenshot, something on your computer is blocking access to vgagent.exe. The file is present, but trying to run it triggers an exception. This is very likely caused by your antivirus software and is not something under VisualGDB’s control. In order to support sending Ctrl-C/Ctrl-Break events to GDB, VisualGDB needs to be able to run this file.

[support]

Thanks, we have found the root cause. It looks like your system has multiple network interfaces marked with the (WSL) tag, so VisualGDB cannot determine the one to use for WSL connections.

We have fixed the issue that was preventing VisualGDB from showing a more descriptive error message in this build: VisualGDB-5.6.5.4337.msi

VisualGDB will now list all the interfaces it found in the error message, so you can manually select the one you would like to use for WSL targets via Tools->Options->VisualGDB->General->Other->Linux Subsystem Network Interface.

[support]

Hi,

It looks like your antivirus is interfering with vgagent. Please see this page for more details.

[support]

Hi,

Please try updating to the latest VisualGDB 5.6 Beta 5 and deleting the .visualgdb subdirectory in the project folder. If the problem persists, please share the updated stack trace, and we will investigate this further.

[support]

Hi,

There is no special command to regenerate a Makefile. It is a part of the project, and deleting it is similar to deleting any other project file. Our best advice would be to create a new similar project from scratch, and try to copy the accidentally deleted files from it, although they may need some adjustment.

[support]

Thanks, we have reproduced the problem on our side. Turns out, the latest Visual Studio 2019 freezes when trying to select a test without a source location (this only affects the simulation platform, as VisualGDB does not support parsing of the DWARF symbols in Win32 EXEs).

We have updated VisualGDB to report a dummy location for these tests. Please try this build: VisualGDB-5.6.5.4323.msi

[support]

Hi,

It looks like you have specified the commands incorrectly. Please try updating them as shown below:

Command: make
Arguments: check

[support]

Hi,

Please try attaching another Visual Studio instance to the frozen one and obtaining the call stack as shown on this page. Please attach the call stack here and we will investigate it further.

[Author]

Posts