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

[support]

Hi,

You should be able to get it working by using the 3-machine setup shown here. You would need to import the custom RISC-V toolchains as a Linux-to-Linux cross-toolchain, disable the automatic deployment tests (you can configure to deploy the project to the same machine), and then override the debug setup.

As far as VisualGDB will be concerned, it will be a Linux-to-Linux project with a completely custom deployment and debugging sequence, so IntelliSense, build error messages and everything else related to build will work out-of-the-box.

To get debugging working, you would need to decide where do you want to run OpenOCD (or another similar program) and where to run GDB. E.g. you can add a custom pre-debug action to copy the built executable to the Windows machine, and then run both OpenOCD and GDB there. Or you could run OpenOCD on the Windows machine, and connect the gdb running on the Linux machine to it.

You can find some pointers and examples on this page; if you need further help, please make sure you can debug everything via command line, and share the details about your manual debugging setup, and we will help you configure VisualGDB to replicate it in the IDE.

 

[support]

Hi,

It mostly depends on what the device vendors do. VisualGDB supports FreeRTOS and ThreadX out-of-the-box (e.g. you can create a project from the wizards) because most device vendors provide FreeRTOS-based and ThreadX-based samples with their SDK, so all we need to do on our side is wrap these samples. If we see more device vendors provide out-of-the-box samples for Zephyr, we will certainly integrate them into VisualGDB.

So far, out of all major vendors, Zephyr is used by the nRFConnect framework, and VisualGDB supports it well. You can create projects via the wizards, VisualGDB will show the thread state via Zephyr thread plugin, etc.

If you want to use Zephyr with devices where the vendors don’t provide the samples, you can always setup the project manually. As far as VisualGDB is concerned, it’s just another CMake-based project, so you will be able to build and debug it as usual. You may need to adjust the thread plugin to accommodate a different stack layout, but that’s precisely the reason we publish sources for our RTOS integration plugins – so you can tweak them for use cases that are not directly supported out-of-the-box.

[support]

Hi,

VisualGDB does not update the system-level variables in order to avoid interfering with other tools. Instead, it sets them for just the process it’s launching to configure and build the project.

You can actually dump the configuration and build command lines to batch files, that show all the environment set by VisualGDB, and can be executed manually in order to simplify troubleshooting things. See this page for details.

If changing the variable globally fixed the project, it could have been hardcoded somewhere else (e.g. by editing the Python scripts) and the value set by VisualGDB was conflicting with it. If in doubt, we always suggest doing a clean toolchain installation, using a clean Python environment and a clean ESP-IDF checkouts. We test them before releasing our toolchains, so they should work just fine out-of-the-box.

[support]

Hi,

Thanks for reporting this, looks like a bug on our side. Please try this build: VisualGDB-6.0.4.5003.msi

[support]

Hi,

Looks like something about your project breaks the linker. As far as VisualGDB is concerned, it starts the build, sees the error message and reports it as expected.

You can try enabling verbose mode, getting the exact gcc/linker command lines, and asking in the binutils mailing lists if you need further help.

[Author]

Posts