[support]

Hi,

Sure. Within Visual Studio, you can use the View->Other Windows->VisualGDB Diagnostic Console.

For command-line builds initiated with VisualGDB.exe, you can set the VISUALGDB_SHOW_DIAGNOSTIC_OUTPUT environment variable to 1.

[support]

Hi,

The optimized WSL backend relies on wsl.exe executable to run WSL commands. E.g. “wsl gcc test.c” would normally just run gcc to compile test.c.

This used to be broken several Windows releases ago, where WSL would randomly hang, so VisualGDB used a much more complicated way to launch commands: it would run a special launcher inside WSL, that would accept a connection via TCP, and would forward the output there. However, this was causing problems with some users’ firewall setups or custom IP address configurations.

So, recently we added an option to use wsl.exe directly again, as the previous bugs we encountered with it appeared to be fixed. We are not aware of any issues with command-line builds. It could be another bug in wsl.exe, or something caused by a particular configuration. If you can narrow it down to a particular wsl.exe scenario, we can try adding a workaround on our side. However, it could be a much easier and safer bet to revert to the “heavy” network-based launching mode.

 

[support]

Hi,

We have just tried doing a clean installation: deleted the entire %USERPROFILE%\.pico-sdk folder, restarted Visual Studio and re-installed Pico SDK 2.3.0 using the VisualGDB GUI. It worked.

You can try first deleting the %USERPROFILE\.pico-sdk\.sysprogs directory and restarting VS, and if it doesn’t help – deleting the entire %USERPROFILE%\.pico-sdk, and re-downloading everything. This should replace any corrupt release list files, resolving the NullReference exception.

That said, the 2.3.0 release should appear under the regular list (not “All Github Tags”) if it doesn’t, it could indicate that something else is broken, so deleting the .pico-sdk directory could be necessary.

Edit: we rechecked the fetching logic, and found the most likely cause. Deleting .pico-sdk\.sysprogs and restarting VS should fix everything nicely.

[support]

Hi,

VisualGDB and the Pico VS Code extension use slightly different project formats. E.g. the VS Code extension hardcodes the SDK version in CMakeLists.txt, while VisualGDB stores it in its own properties file.

You might be able to get it working by creating 2 projects side-by-side, and merging them one step at a time, but it could require some non-trivial troubleshooting and is generally not recommended.

If you want full interoperability with VS Code, you may want to try VisualGDB for VS Code (visualgdb-vscode-0.0.1.vsix). It transparently translates the VS Code variables to CodeVROOM, so you can just click Open Workspace in VisualGDB inside VS Code, and immediately get the VisualGDB GUI for your project.

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, and good to know it works.

BTW, if you are looking into VS Code, feel free to check out the latest daily build of CodeVROOM. It’s a subset of VisualGDB that works outside Visual Studio (also on Linux/Mac).

It’s extremely lightweight (30MB download), doesn’t need installation, and has multiple improvements over the regular Visual Studio GUI. E.g. the Live Watch is integrated into the regular expression popups, so you can inspect the global variables with mouse while the target is running:

The last build is still missing a few pieces like plotting, but has all the major parts, and works with Pico SDK out-of-the-box. So, you can use VS Code with the Pico extension to get the latest versions of all tools, and still have the advanced debugging GUI from VisualGDB.

• This reply was modified 1 week, 1 day ago by support.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks for confirming your license key. It was linked to another email address, and our system picked up an old license instead.

The error comes from VisualGDB trying to download the PicoSDK referenced by the project (or one of the tools required by the SDK). Normally, it would only happen if the project references an SDK version that is not present on your computer.

You can try creating a new project from scratch to see what SDK versions are available. If the project you are opening refers to a different one, it would not work without an Internet connection.

If it doesn’t help, please let us know the VisualGDB build number from the Help->About VisualGDB window, so that we could look further into what is going on.

[support]

Hi,

It could be that the project is just too large. Code coverage means reserving a small portion of device RAM for every branch in the code, so that the instrumented program can track whether that branch was ever taken.

If the program was approaching the limits of the RAM/FLASH already, it could very easily push it over the limit. Typically, it would be used with unit tests, so you could just try splitting the test executable into multiple smaller ones.

You can also try temporarily patching the linker script to increase the FLASH/RAM size by 10x to see how much space would the current setup need.

[support]

Hi,

Sorry, VisualGDB 5.6 is very old and long discontinued. Please consider updating to the latest v6.1.

[support]

Hi,

The easiest way to get it working would be to create a brand new CMake project containing just a couple of source files, enable the code coverage there, and make sure it works as intended. You can then use it as a reference, comparing to the big project that doesn’t work.

[support]

Hi,

The absolutely safest way to go would be to install the Espressif’s VS Code extension, let it install all the necessary tools, and then use VisualGDB’s consolidated toolchain mode where it reuses the Espressif’s own tool layout.

So, if it works with the Espressif’s own VS Code extension, it will work with VisualGDB as well.

Also a heads up that we just finished porting a big chunk of the debugger-related functionality to CodeVROOM, and are expecting to release v0.6 with ESP32 debugging support in about a month. This way, you’ll be able to use a lot of VisualGDB’s debugging, navigation and settings editing GUI for the VS Code projects, without having to import them into the “Big” Visual Studio. It will also work directly on Linux and Mac where the 255-character path limitation does not exist.

[support]

Hi,

Strange. Based on the screenshots you provided, it should work.

You can try a workaround like this:

1. Create a decover.bat file that runs VisualGDB with the response file.
2. Make sure it works when running manually. Note that the relative paths in the response files will be resolved against the working directory of VisualGDB.exe. So, you may want to hardcode full paths there for testing.
3. If it works, try updating CMakeLists.txt to just run the batch file. If it still works differently, you can try adding echo commands to the batch file to recheck that it actually gets invoked.

[support]

Hi,

This could a bit tricky. VisualGDB uses two-level approach when indexing sources:

1. The solution can have one or more projects (top-level nodes in Solution Explorer, typically created by running the project wizard).
2. Every project can have one or more targets (individual static libraries, executables, etc.).

VisualGDB maintains a separate code index for each project, so it generally expects that every source file would only appear there once, regardless of the number of the underlying targets.

If you want to work with multiple instances of the same file built with different flags, you would need to restructure your solution into multiple projects. Then VisualGDB would detect that the file is used by several projects, and would allow choosing one via a combo box in the top left corner of the editor. However, that would create some complications (e.g. you would have a separate set of configurations/debug settings for each project, and you would need to be careful with inter-project dependencies).

Another option would be to have multiple build configurations (e.g. Debug-SDCard vs Debug-NoSDCard) and use CMake conditions to remove irrelevant targets from the configurations.

[support]

Hi,

The % syntax may not work correctly. We have updated VisualGDB to support the @-syntax in this build: VisualGDB-6.2.0.5619.msi.

E.g. /decover output.elf @inputs.rsp

If you are not sure what syntax Cmake is using, you can temporarily replace the custom command line with “cmd.exe ARGS /c echo VisualGDB.exe /decover …”. This will echo the actual VisualGDB command line instead of running it, so you can use it for troublehsooting.

[support]

Hi,

This could indeed be caused by the command-line length limit. VisualGDB’s code coverage support relies on patching all object files before the final linking takes place. This is defined in the coverage.cmake file under the VisualGDB\BSP directory:

add_custom_command(TARGET ${target_name} PRE_LINK COMMAND "$ENV{VISUALGDB_DIR}/VisualGDB.exe" ARGS /decover $<TARGET_FILE:${target_name}> ${_effective_sources})

If the _effective_sources list gets too long, it could indeed cause problems.

We can easily update VisualGDB to support the response file syntax (target name @<source list file>), but we are not aware of a straight-forward way to force CMake to use it for custom commands. You can try patching the CMake file on your end using temporary workarounds (e.g. manually generate a temporary list). If it works, we can easily upload an updated VisualGDB build with support for the @-syntax in that command.

[support]

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

[Author]

Posts