Forum Replies Created
-
Posts
-
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.
No problem, please see the following page for details: https://visualgdb.com/tutorials/arm/tests/resources/
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.
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.
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.
Hi,
It looks like your antivirus is interfering with vgagent. Please see this page for more details.
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.
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.
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
Hi,
It looks like you have specified the commands incorrectly. Please try updating them as shown below:
Command: make
Arguments: checkHi,
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.
Hi,
Most likely, you are building the deprecated HLA_Multicore platform. Please try switching it to Mainstream via the VS platform selector.
We have also just updated the repository, removing the HLA_Multicore platform completely.
Hi,
According to our records, your support period has expired. Please kindly renew it here and we will help you get everything working.
Hi,
This is an Arduino-based project and not an ESP-IDF-based one. Arduino projects use the Arduino build system that can be considerably slower than CMake+Ninja.
Either way, you can try building the project outside VisualGDB as shown here: https://visualgdb.com/documentation/projects/arduino/#troubleshooting
Thanks for renewing your license. The slow build might come from the GNU Make tool used by the ESP32 projects. Please make sure your project uses CMake and Ninja, and not the legacy GNU Make. You can recheck it via VisualGDB Project Properties -> CMake Build Settings.
If this doesn’t help, please try exporting the configuration and build command lines from VisualGDB to batch files as shown here. Does running them manually also result in a slow build?
