Forum Replies Created
-
Posts
-
Thanks for renewing your licenses today. Please find the detailed answer to your inquiry below.
The way VisualGDB stores settings for different configurations depends on the project type. For VC++-based projects (e.g. MSBuild, legacy GNU Make, etc), VisualGDB creates a separate .vgdbsettings file for each configuration. For advanced project types, settings for all configurations are the same and are stored in the .vgdbproj or .vgdbcmake file.
That said, you can use the $(ConfigurationName) variable throughout VisualGDB Project Properties to distinguish debug/release configurations. Specifically, for Make-based ESP-IDF projects, you can set VisualGDB Project Properties -> ESP-IDF Project -> SDKConfig File to sdkconfig-$(ConfigurationName) (you would need to copy it manually) and VisualGDB will use it when configuring the project. We have updated the tutorial to reflect this.
You can double-check the file used by VisualGDB by searching the build log for “SDKCONFIG=”.
Custom build steps are indeed shared between the configurations as well, however you can work around it by using the “Reference a reusable action list” step that links to another file with steps. Simply link to a ExtraSteps-$(ConfigurationName).xml file, and VisualGDB will load 2 different files depending on the selected configuration.
Hi,
No problem, we can investigate this further. Please try updating to VisualGDB 5.6 Beta 5. If the problem persists, please try reproducing it on a clean project from scratch and sharing the repro steps we could follow on our side per our problem reporting guidelines.
Oh, thanks for pointing this out. We had the same issue with the RISC-V toolchain where our toolchain build passed the tests, but the official one did not.
Our latest ARM toolchain release has fully passed our internal tests with VisualGDB 5.6, so the Ninja executable shipped with it must include a workaround for it as well. In this case, updating to it should be a safe bet.
Hi,
This is a known bug of some of the Windows GCC builds: due to some reason, the paths inside the .dep files end up escaped incorrectly. We updated the VisualGDB itself (i.e. MSBuild) to handle the broken paths properly a while ago, but this won’t help with the external tools like Ninja.
Generally, please try using our latest ARM toolchain. It’s built from the official GNUARM sources using the official instructions (+flags enabling support for big-endian devices), and does not have the path encoding bug (we don’t know why the official release does).
You can also try replacing the Ninja executable in the VisualGDB directory with the latest release (or updating to VisualGDB 5.6 that includes a newer version), but this may not work either.
Hi,
According to our records, your support period has expired. Please kindly renew it here and we will help you get everything working.
Hi,
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.
Hi,
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.
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.
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).
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.
Hi,
This is a known issue that was fixed in VisualGDB 5.6 Beta 5. Please try updating to that version.
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.
