[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

[support]

Hi,

Thanks for sharing this!

[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

[support]

Sure, here you go.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

We have rechecked it with the ESP-IDF 6.0.2 (default settings, default ESP32 device) and it worked just fine:

------------------- Memory utilization report -------------------
Used DATA_FLASH: 27KB out of 4096KB (0%)
Used INSTR_FLASH: 45KB out of 3264KB (1%)
Used DATA_RAM: 12KB out of 176KB (6%)
Used INSTR_RAM: 41KB out of 128KB (32%)
Used EXTERN_RAM: 0 bytes out of 4096KB (0%)
Used RTC_DATA: 0 bytes out of 8192 bytes (0%)
Used RTC_IRAM: 0 bytes out of 8192 bytes (0%)
Used RTC_SLOW: 40 bytes out of 8168 bytes (0%)
Used Unknown: 24 bytes

It could be something about that particular project that is causing the issue. Please consider reproducing it on a clean project created from scratch.

[support]

Hi,

Are you using Advanced CMake? The smart configurators are CMake-based, so they require the CMake build subsystem.

[support]

Hi,

Please try using File->New->Project/Solution and then searching for VisualGDB there. It should show the VisualGDB wizards just fine.

[support]

This could be a bug with the VS cache then.

You can try uninstalling VisualGDB, uninstalling VS2026, completely removing VS2026 directory, reinstalling VS2026, and reinstalling VisualGDB. This should fully reset all caches.

[support]

Hi,

If About VisualGDB command appears in both VS instances, the wizards should work as well.

You can double-check it by explicitly searching for “VisualGDB” in the wizard window, or using the separate File->New->VisualGDB Project command that just shows the wizards provided by VisualGDB.

[Author]

Posts