Forum Replies Created
-
AuthorPosts
-
September 17, 2021 at 08:06 in reply to: ESP-IDF project and per-configuration sdkconfig files #31336
support
KeymasterHi,
According to our records, your support period has expired. Please kindly renew it here and we will help you get everything working.
September 15, 2021 at 11:32 in reply to: IDF 4.3.1 needs toolchain update to (xtensa-esp32-elf-gcc8_4_0-esp-2021r1) #31328support
KeymasterHi,
No problem. We normally wait until the toolchain is released via the Espressif’s toolchain installer (otherwise it often just doesn’t work due to missing files or compatibility issues), however this time it looks like due to some reason they didn’t update the installer despite releasing a fairly stable toolchain.
Either way, we have updated our ESP32 toolchain to include the 2021r1 tools and ESP-IDF 4.3.1, and verified that basic projects can be built and debugged. You can download the new toolchain via VisualGDB Package Manager, or directly here.
support
KeymasterHi,
Code Explorer has been introduced in VisualGDB 5.6 Beta 5. Please make sure you update to it, and it will appear automatically. You can also manually activate it via View->VisualGDB Code Explorer.
September 15, 2021 at 08:04 in reply to: Error with 'Microsoft.VisualStudio.Package.Variant' after updating to VS 16.10 #31326support
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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.
September 14, 2021 at 11:16 in reply to: Instrumenting Profiler .elf not correctly released by Visual Studio #31317support
KeymasterHi,
This is a known issue that was fixed in VisualGDB 5.6 Beta 5. Please try updating to that version.
support
KeymasterThanks 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
KeymasterNo problem, please see the following page for details: https://visualgdb.com/tutorials/arm/tests/resources/
support
KeymasterHi,
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
KeymasterHi,
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
KeymasterThanks, 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
KeymasterHi,
It looks like your antivirus is interfering with vgagent. Please see this page for more details.
support
KeymasterHi,
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
KeymasterHi,
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.
-
AuthorPosts