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

[support]

Hi,

No problem. Please let us know the email address associated with your license key, and we will look further into it.

[support]

Hi,

The ESP-IDF projects support multiple targets per project (i.e. libraries/components), hence typically there is only one project per solution, even for complex projects with reusable code. While having multiple ESP-IDF projects in the same solution is supported, it is somewhat a rare case and it may indeed not be 100% perfect. More specifically:

1. The recompilation is managed by the ESP-IDF itself. VisualGDB simply invokes CMake/Ninja to build the project. You can try adding “-v” to Ninja arguments to see what is going on, but either way it’s not directly controlled by VisualGDB.
2. You can reload the projects one at a time by right-clicking on them and selecting “Reload”. The initial loading after opening the solution will indeed be done simultaneously. As multiple ESP-IDF projects is a relatively rare case, we will not be optimizing this specific part, sorry.
3. As most ESP-IDF-based setups use one project per solution, the test logic indeed doesn’t show the project name. If you have to use multiple ESP-IDF projects in the same solution, please consider answering “no” in the initial prompt and reloading projects one-by-one via context menu. This will show the prompts for the corresponding projects separately.
4. This again comes from the way the ESP-IDF framework supports tests. You can try patching the ESP-IDF scripts to only build unit tests when a specific configuration variable is defined. If this gets the tests working via command line, but not in VisualGDB, we can try updating VisualGDB to recognize them properly unless it would require a large amount of changes.

[support]

No problem. Feel free to share an update here once you get the steps we could follow to reproduce the problem, and we will look further into it.

[Author]

Posts