[support]

From the VisualGDB side, there is no difference between these cases. If you can build the project via command line outside VisualGDB, you can import it into VisualGDB as shown in the tutorial. If you cannot build it outside VisualGDB either, simply importing it into VisualGDB will not automatically fix the build issues.

[support]

Hi,

Sorry about the confusion. Please consider updating to VisualGDB 5.6 Beta 5. It supports installing the .vgdbpkg files directly from the Package Manager.

[support]

Hi,

No problem, we have updated our package list page to show auxiliary packages, such as CMake. You can install the downloaded package files via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Hi,

You can import existing projects into VisualGDB using the “import” mode in the wizard as shown here: https://visualgdb.com/tutorials/arm/import/

[support]

This could be related to a VS MEF cache bug. Please try restarting Visual Studio. If it doesn’t help, please try right-clicking on the tab header of the source file that is not loading, and select “copy full path”. Please share the full path here, and we will help you get it working.

[support]

We usually answer most inquiries within 1-2 business days. There is no need to create multiple tickets for the same issue, as they go through the same queue anyway.

Please note that the exact logic for recompilation it managed by ESP-IDF and not by VisualGDB. As far as our support goes, we can help if VisualGDB working on top of ESP-IDF produces different results from using ESP-IDF directly. For all issues that are also present in the ESP-IDF itself, please contact Espressif.

Regarding the max. items per CMakeLists line, VisualGDB picks it up automatically. For each statement, it detects and preserves:

• The indentation of the 1st line
• The indentation of other lines
• The number of items on the 1st line
• The max. number of items on other lines

Hence, there is no need to change any settings. Simply format the statement the way you prefer, and VisualGDB will preserve it when updating the statement.

[support]

Thanks for the detailed description. This looks like an issue with the environment variable expansion that was fixed in VisualGDB 5.6.

The stack trace looks like VisualGDB is trying to read the contents of one of the source files on the remote machine. It could freeze VS if the project contained files called aux.c or com[1-4].c, although VisualGDB 5.6 contains a check for this. Either way, please try updating to the latest Beta (or VisualGDB-5.6.5.4391.msi) and let us know if the problem persists.

[support]

Hi,

No problem. If Visual Studio locks up, please try obtaining a stack trace as shown here. If it contains VisualGDB  frames, please attach it here along with your VisualGDB build number, and we will investigate further.

The second issue looks like your gdb executable crashes. Please first make sure you can debug your program manually by running gdb manually on the same machine and with the same gdb you are intending to use with VisualGDB. If you can do that without crashing, we can gladly help you configure VisualGDB to replicate the same setup.

If the toolchain appears broken and doesn’t work, we can also gladly investigate it your you and build a custom toolchain that will work with your target. Feel free to reach out to our sales if you would like to get a quote on that.

[support]

Hi,

Please try updating to VisualGDB 5.6 Beta 5. It contains a fix fully resolving this issue.

[support]

Hi,

No problem. Please refer to our MSBuild documentation page for a detailed description of different files used by VisualGDB projects.

[support]

Hi,

Thank you for attaching the screenshot. We could definitely add a setting for controlling the code page used by VisualGDB when parsing the gdb output if it was affecting one of our paid users. Please consider purchasing a license and we will be happy to add this setting.

[support]

Hi,

Please attach a screenshot of your Help->About VisualGDB window so that we could see what is going on.

[support]

Thanks for the clarification. The user variables defined via VisualGDB Project Properties indeed work differently. Their values are saved to the .user file each time you edit them via VisualGDB Project Properties, and are read throughout the build process.

The variables set via custom build/debug steps only persist until the end of the corresponding operation. For non-MSBuild projects that would be the entire build. For MSBuild-based projects they are guaranteed to persist between multiple pre-build steps in the same sequence, but not between pre-build steps and the actual build.

[support]

Hi,

Thanks, this explains it. In this case, due to the way Visual Studio handles project files, it may indeed throw the same exception it does when VC++ support it missing. As a workaround, please try unchedking the “Rename the Visual Studio project to match the imported project name” checkbox on the first page of the Embedded Project Wizard.

[support]

For MSBuild projects, the VisualGDB-level variables should not be automatically propagated to MSBuild level, unless you configured some mechanism to do it manually. If you can share the screenshots of your setup (how you configured the variables and how do you observe them propagated), we will try to explain what is going on.

[Author]

Posts