[support]

Hi,

Based on the screenshot you attached, you have 2 instances of OpenOCD running simultaneously (one in the terminal and another launched via VisualGDB). This will indeed not work, as they will conflict with each other.

Please make sure you only have one instance at a time.

[support]

Hi,

This looks like a question about the ESP-IDF framework and not something specific to VisualGDB. Please consider asking on the Espressif forums instead. Any advice they may suggest will also work with VisualGDB.

[support]

Hi,

No problem, we will try to help you. Please try clicking the “show exception details” link and share the stack trace shown, there as long with the VisualGDB build number from the Help->About VisualGDB window.

[support]

Thanks for renewing your support.

This error would happen if the project file would be corrupt (e.g. edited manually). The easiest way to troubleshoot it would be to create another similar project from scratch, make sure it builds, an then compare the .vcxproj files one-by-one, specifically the PropertyGroup parts.

If there are too many differences, you can try merging half of them at a time (i.e. replacing the XML tags with the ones from the other file) and reopening the solution to see if it solves the problem.

[support]

Hi,

In general, we would advise migrating your project to Advanced CMake. You could then organize your project to have multiple platforms, each targeting a specific MCU, and multiple targets (applications/libraries) reusing the same MCU definition from the platform. E.g. see this tutorial.

If you would like to keep MSBuild instead, you would need to fork the mcu.xml and mcu.props files and update the references as shown below:

Location	Element	Target
MSBuild projects properties -> Embedded Project	MSU Build Settings File	New mcu.props file
MSBuild projects properties -> Embedded Project	VisualGDB Settings File	New .vgdbsettings file
New .vgdbsettings file	<EmbeddedProfileFile>	New mcu.xml file

This will keep the settings in multiple configurations/platforms separate from each other.

[support]

Good to know it works.

The STM32CubeMX generator insists on generating the main file so that it could automatically switch between non-RTOS vs. FreeRTOS configurations, that have a completely different initialization sequence, but we do agree that it is not very convenient.

If you absolutely want to override it, you can mark the file as “excluded from build” via the context menu, and provide your own main file, however it could cause weird conflicts in case the logic in STM32CubeMX changes in future versions.

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[support]

Thanks for the screenshot.

It looks like you are using ESP-ADF, not the regular ESP-IDF, and there was indeed a bug in VisualGDB preventing it from showing the device list for ADF projects.

Please try this build: VisualGDB-5.6.108.4753.msi

[support]

Hi,

You can change the device type via VisualGDB Project Properties -> ESP-IDF Project -> Configuration Settings -> Device.

[support]

Hi,

This happens because CMake projects contain multiple targets, and setting the target_compile_definitions() for one target does not automatically affect others.

You can find the list of targets (executables + static libraries) in Solution Explorer, or by analyzing the target-XXX.json files in the .visualgdb\VisualGDBCache subdirectory.

If you are trying to setup a complex project layout involving multiple targets, we would advise first sketching how many targets it would involve, how they would reference each other, and then setting up the target_compile_definitions() accordingly. If you are new to CMake, we would advise reading about the public/private/interface definitions – it will help you setup everything efficiently.

You can also use our CMake Debugger to step through the CMakeLists files and see how and where various settings are applied.

[support]

Thanks, we have received and reviewed the dump file. The crash happens because Clang considers one of the headers it’s precompiling to contain a typo preventing the normal parsing, and it apparently triggers a “not implemented” condition when trying to produce the precompiled header data.

You can work around it by adding a non-preprocessor statement (e.g. ‘static int unused=0;’) at the beginning of the file to suppress the precompiled header generation. Then you can try moving the statement between the #include<> directives until you find the one that is triggering the issue. Having that include directive after the non-preprocessor statement will prevent Clang from trying to precompile that header file, working around the crash.

[support]

Hi,

Normally VisualGDB should automatically create a dump file containing sufficient information for us to pinpoint the issue. If this doesn’t happen, please try attaching another VS instance to the CppEngineHost64.exe process (make sure you explicitly select the Native mode), wait for the crash to happen and then create a dump file via the Debug->Save Dump command.

You can attach the dump file here, or simply submit it to us via the support interface and we will try to find the root cause of the issue and release a hotfix.

[support]

The target-independent parts of VisualGDB (.Net IL libraries) will indeed work. However, the native parts (x86 and x64-specific) will not. Furthermore, all external tools (e.g. OpenOCD, toolchains) will have to rely on the x86 emulation, making them considerably slower. Driver compatibility could be another big issue.

So, it could be fairly easy to get it to a proof-of-concept level, but getting a reliable development environment that can be used for non-trivial projects could be orders of magnitude more complex, and may still not work out due to lack of support from external tools.

We will watch the user interest in ARM64 and the adoption of the Windows ARM64 platform by the GNU tool ecosystem, and will add support for it when there is enough momentum. If you are serious about using an ARM64 Windows host for development with GNU tools, please consider contributing to the ARM64 MinGW port. It will speed up the ARM64 adoption by the community by making it possible to do native builds of tools like OpenOCD and GCC/GDB. Once these tools are natively supported and start being used by the community, the ARM64 port of VisualGDB will make more sense.

[support]

Thanks for letting us know and good to know it works.

[support]

Hi,

We are aware of that. ARM64 laptops are still very new, relatively rare, and are seldom used as development workstations. Hence, VisualGDB does not support running on the ARM64 Windows builds.

We will continue monitoring the situation and will consider supporting ARM64 development machines if they become more popular among developers.

[Author]

Posts