[support]

Thanks for the update.

This could be related to the order in which the tasks are loaded. You can try this build [VisualGDB-6.2.0.5625.msi], we added an extra check there.

That said, MSBuild projects with the VS IntelliSense engine is considered a legacy setup, so we won’t be doing major changes there. For new projects, we recommend Advanced CMake.

If you are not using Clang IntelliSense due to particular limitations (e.g. indexing the entire project when navigating to definition), we are working on a few optimizations to that. If you have a particular scenario that is slow, we can look into optimizing it. It also works way faster when running directly on Linux or Mac using our cross-platform CodeVROOM shell (e.g. see this tutorial), as a lot of its performance bottlenecks come from the Windows limitations when dealing with multiple small files.

[support]

Hi,

This could happen if the project was manually edited with some custom targets or build rules, overriding the default VisualGDB target order.

The first step to diagnose it would be to create a new project from scratch and check if it works fine. If yes, you would need to analyze the differences between the 2 projects, open them side-by-side, and try narrowing this down to a specific setting or a custom target.

[support]

No problem. A good starting point would be to make sure you can build the project from command line outside the Atmel Studio. Once it works, you can select “project built with command-line tools” and specify the command lines there.

[support]

Hi,

There will never be an import tutorial that will work exactly one-to-one with a particular project. There simply too many different project layouts, options, etc.

A good starting point would be to understand the project structure, where different parts come from, and how they are related.

If you have questions about a specific setting that is different between the GUI and the tutorials, we can help, but these differences are usually trivial.

Another option would be to keep building the project in Atmel Studio, and use Quick Debug to debug it.

[support]

Hi,

No problem, this should be fairly easy to fix. Just to double-check, are you using the same toolchain in all the configurations?

[support]

Sure, you can use this page: https://sysprogs.com/splm/mykey

It shows the download link for the last compatible version, and also gives the renewal quotes.

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

[Author]

Posts