[support]

We have just rechecked the settings testing GUI. OpenOCD indeed shows the “Error on socket” message (because VisualGDB closes the socket abruptly after confirming that it works) , but VisualGDB still shows the correct “Connection test succeeded” message. If you actually get an error message box instead, please feel free to attach a screenshot and we will investigate.

As for idf.py erase-flash, it is really something to check with Espressif. The idf.py file and all logic inside it comes from them. We don’t touch it, we don’t run any comprehensive tests on it beyond checking for unsatisfied dependencies, and rely on Espressif to fix issues in it.

You can try installing ESP-IDF 5.2 into the IDF 5.1 toolchain via the first page of VisualGDB Project Properties. Based on some quick tests, it is compatible with that toolchain, and might include some additional fixes.

[support]

Hi,

Sorry about that. This comes from the workaround used by VisualGDB to automatically resize List View columns. It tries to dynamically recompute the width of the Expression column based on the others, and it sometimes collides with the native WPF logic for resizing the columns.

Please try the latest VisualGDB 6.0 Beta 3. It defers the auto-resizing until you release the mouse button, so it should not interfere with the normal resizing and have this effect.

[support]

Please make sure you have a solid understanding of the following topics:

• How include search paths work, and how they are different from adding header files to Solution Explorer. We have a tutorial on this here, but you can find plenty of information from other sources as well.
• How C linking works, what are object files, libraries, library search directories and how symbol definitions are different from declarations in header files. We have another tutorial on this here.

These are fundamental C topics, and most VisualGDB features are designed assuming that the user is familiar with them. Trying to edit various files and using features like Header Discovery without understanding these will only cause cascades of increasingly strange errors.

Specifically to your questions:

1. This is the correct approach.
2. You can try using the “Add->Import folder recursively” command in the context menu or shared items projects.
3. Adding the top-level folder to the include search directories should not automatically add subdirectories.

[support]

Hi,

Sure, VisualGDB provides a special mechanism for fine-tuning that behavior:

1. It defines a __SYSPROGS_CODESENSE__ macro on the IntelliSense level. The macro is not defined during build, so all code enclosed in #ifdef __SYSPROGS_CODESENSE__ will only affect IntelliSense.
2. It forcibly includes %VISUALGDB_DIR%\gcc_compat.h file when using IntelliSense. The file contains various empty definitions for various macros that would otherwise cause errors.

You can eliminate the errors you mentioned by adding the following lines in gcc_compat.h (inside #ifdef __IAR_SYSTEMS_ICC__):

#define __no_init
#define __root

It will only affect IntelliSense and will not interfere with the build.

 

[support]

Hi,

This is to be expected. Different ESP-IDF versions are not 100% backwards-compatible, so the project may need some adjustment. If deleting the temporary subdirectories (build and .visualgdb) doesn’t resolve the problem, the project probably uses some settings that changed between the ESP-IDF releases.

VisualGDB cannot perform this kind of troubleshooting fully automatically. All it does in this case is notices that some header files referenced by sources are not present anywhere in the search path, and tries to automatically locate them and suggest the missing directories. This feature was designed to simplify importing of external projects (see this tutorial) and we do not recommend using it in this case. ESP-IDF projects specify many settings on a higher level, and overriding the include paths manually can create more problems than it would solve.

A good way of solving it would be creating a new project from scratch, checking where the missing include files are usually located and how are these components referenced, and then porting these settings to the broken project. You will likely find that some component names have changed, or some CMake-level statements use slightly different syntax.

[support]

Hi,

It really looks like something between the Espressif’s OpenOCD port and the chip. We are not affiliated with Espressif and do not have insights into their chips or tools beyond their official documentation.

If you suspect VisualGDB is using OpenOCD incorrectly, you can always try running the binaries from Espressif manually. If they also don’t work, please contact Espressif for further help. If they do work, please try comparing the command lines between the working and broken setup. If you can point out a specific difference causing the issue, we can gladly investigate it further.

That said, we have recently updated our OpenOCD package to match the latest release from Espressif. Please try installing it via VisualGDB Package Manager. It may contain a fix for this specific issue.

[support]

Hi,

OK, we’ve done some more investigation. It turns out the CoPilot extension pulls a dependency on the System.Windows.Interop.RenderingMode type, that somehow causes errors when trying to load XAML controls that have any non-dependency property called “Mode”.

There were a couple of more instances of these controls in VisualGDB code base, although they only affected a handful of settings pages.

We have fully resolved the issue to the following build: VisualGDB-6.0.4.5041.msi​. We renamed all conflicting properties and added an internal check for such conflicts to our build process.

[support]

Hi,

This indeed looks like a bug of the pic32 compiler. Please try running gcc manually using the command line shown in the error message. If it still fails, please consider reporting it to Microchip.

[support]

Hi,

Thanks for confirming your license. The ESP32 builds are managed by the ESP-IDF build scripts, that indeed do not define separate debug/release macros on the C/C++ level.

You can work around it by adding the following line to the top-level CMakeLists.txt file of your project, before the first include() statement:

add_compile_definitions(${CMAKE_BUILD_TYPE})

[support]

Hi,

Thanks very much for pointing it out. We usually try to keep regular expressions and search strings in a separate file (%VISUALGDB_DIR%\Rules\RegularExpressions.xml) to facilitate exactly this kind of hotpatching, but the “(WSL)” rule wasn’t stored there yet.

Feel free to try this build: VisualGDB-6.0.4.5016.msi. We have updated the rule to match both new and old name, moved it to RegularExpression.xml (RegularExpressionCollection/Other/WSLInterfaceName), so it can be easily edited in case it changes again.

[support]

Sorry, we are not aware of any specific setting that would interfere with it. If one project works distinctly different from another one, you can try comparing the project files side-by-side and merging differences between them to see at which point the behavior changes.

[support]

Hi,

No problem, please find the answers below:

1. You can use the View->Other Windows->VisualGDB Diagnostics Console window to see the exact low-level commands issued by VisualGDB.
2. You can uncheck the “Automatically test the connection” checkbox at the bottom of the target selection page in the wizard. VisualGDB will still verify that the toolchain works (i.e. produces something), but won’t try to deploy it.
3. You can do that fairly straight-forward with the Custom edition – change the GDB host to Windows, specify OpenOCD as the custom gdb stub, and add a custom pre-debug action that will copy the file (just “cp $(TargetPath) /mnt/c/deployment/dir”). If you are using a lower edition, you can upgrade it here. If you do not want to upgrade, you can create wrapper scripts on the Linux subsystem that would run commands on Windows (e.g. by running an SSH server on Windows) so from the VisualGDB’s point of view, everything still runs on the build machine, but it could be worthwhile to use the Custom edition that was specifically designed to handle such setups.

[support]

Hi,

Please let us know the email address associated with your license key so that we could link it to your forum account.

[support]

Thanks, we have linked your license to your forum account.

We have rechecked the DEBUG/RELEASE flags for CMake projects and indeed they got broken when we added an option to select between size and speed optimization.

We have fixed it on our side and will include it in the next Beta. As a workaround until then, you can simply patch the C:\Program Files (x86)\Sysprogs\VisualGDB\CMake\embedded\root.cmake file as shown below:

 if("${VISUALGDB_TOOLCHAIN_SUBTYPE}" STREQUAL "GCC")
- set(CMAKE_C_FLAGS_DEBUG "-g3 -O0")
+ set(CMAKE_C_FLAGS_DEBUG "-g3 -O0 -DDEBUG")
set(CMAKE_CXX_FLAGS_DEBUG ${CMAKE_C_FLAGS_DEBUG})

#Add "OPTIMIZE_FOR_SIZE=1" to Extra CMake Configuration Variables in VisualGDB Project Properties in order to optimize the release build for size, rather than speed.
if(OPTIMIZE_FOR_SIZE)
- set(CMAKE_C_FLAGS_RELEASE "-g3 -Os")
+ set(CMAKE_C_FLAGS_RELEASE "-g3 -Os -DRELEASE")
else()
- set(CMAKE_C_FLAGS_RELEASE "-g3 -O3")
+ set(CMAKE_C_FLAGS_RELEASE "-g3 -O3 -DRELEASE")
endif()

[support]

Hi,

Sure, this is already supported via the Visual Watch plugins. You can use the Debug->Visual Watch command to display arrays as graphs or images.

You can also create your own Visual Watch plugins to cover the cases not supported directly. E.g. you can fork our ImageWatch plugin and replace the version in “C:\Program Files (x86)\Sysprogs\VisualGDB\VisualWatchProviders” file, or place it under a different name to the same directory, or under %LOCALAPPDATA%\VisualGDB\LiveWatchProviders.

[Author]

Posts