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

[support]

Thanks for clarifying this. If the toolchain is not based on GCC, you can simply create a custom Makefile for building your code and import it into VisualGDB as an externally built project. This way VisualGDB will simply invoke make with the specified arguments to build the project and won’t care that the underlying tools are not based on GCC. If the tools report error messages in a non-typical way, you can tweak VisualGDB to recognize them by editing %VISUALGDB_DIR%\Rules\RegularExpressions.xml.

On the debugging side, if the vendor provides a gdb executable for their platform, you can use VisualGDB to debug the code by overriding the gdb path via VisualGDB Project Properties. If they use a completely proprietary debugging protocol, we can still add support for it as a custom paid feature, but it would be a rather complex one.

[support]

Hi,

We provide out-of-the-box integration for mainstream devices with many active users, however this looks like a much more niche device with a smaller user base. Hence, we will not be supporting it directly unless some of our users agrees to directly cover the cost of integrating VisualGDB with it.

That said, VisualGDB is designed to be very flexible. If the device vendor provides a GCC-based toolchain, you can simply import it into VisualGDB by using the import link in the toolchain selector. Then, you can follow this tutorial to manually specify the compiler flags and locate the driver files necessary for that device. This way you can enjoy most of the VisualGDB functionality even if the device is not directly supported by us.

 

[support]

Hi,

Thanks, we have confirmed the issue and released an updated toolchain resolving this (R5).

Regarding OpenOCD, our build is indeed based on a slightly later Git revision than the official binary release, so it might work a bit better. Although the credit goes to Espressif – our changes to OpenOCD are related to better integration with VisualGDB and don’t affect the device-specific part at all.

[support]

Hi,

Sorry it took longer than expected with the CC3220 update, as the amount of changes to the SDK was a bit more than we anticipated. We have just released an updated BSP based on the latest SDK 5.20. You can install it conveniently via VisualGDB Package Manager.

[support]

Hi,

No problem, please refer to the following page for more details: https://visualgdb.com/documentation/gdb/frozen/

[support]

No problem. Please try this build: VisualGDB-5.6.5.4379.msi

The regular outline still shows the hierarchical structure of the source file, but you can now switch the detail view to show a plain list of all symbols, rather than local references or structure.

BTW, the Globals view in Code Explorer is extremely optimized. It can show a huge number of symbols, and allows quickly filtering them by names or types. It can also track things like references between types (e.g. all types that have fields of type X) or functions allocating/deleting types (i.e. recognizing patterns like (Type *)malloc(…)).  If you haven’t checked it out yet, it’s worth a try.

[support]

Hi,

Normally, the disassembly warning should not crash Visual Studio. If this happens, please feel free to obtain a stack trace of the crash, and attach it here along with your VisualGDB build number.

You can also increase the disassembly deactivation timeout via settings (Tools->Options->VisualGDB->General->Debug->Disassembly reading timeout).

[support]

Hi,

The logic that copies the file first time you change it indeed doesn’t resolve the variables (we will fix it in the final v5.6 release), and will try to use an incorrect name, however the rest of the GUI will work just fine, as long as you create the sdkconfig-debug and sdkconfig-release files manually.

The GUI for editing the configuration values queries the full path to the SDKConfig file from the ESP-IDF build subsystem, so it will always edit the configuration for the currently loaded configuration. If you would like to edit settings for another configuration, please select it in the VS configuration manager first, so that VisualGDB can query its layout from the ESP-IDF build scripts.

[support]

Hi,

Please try running vgagent.exe manually (e.g. vgagent.exe cmd.exe should start cmd.exe). If it’s not starting, something on your computer is preventing it from starting.

[support]

Thanks for your feedback. Just to clarify, do you mean the list of all functions in the current source file, or in the entire solution?

[support]

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.

 

[support]

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.

[support]

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.

[support]

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.

[Author]

Posts