[support]

Please make sure you can get it fully working outside VisualGDB first. Once it works, please feel free to share your findings (what exactly you did and what results you observed) and we will help you configure VisualGDB to replicate the results.

Update: we have done some brief experiments with a regular ESP32 chip with mixed results. Cloning the example you mentioned does get the stub running, but trying to connect gdb to it fails with the “no registers” message, that would typically happen if the stub and the gdb executable used incompatible register formats. Given that the official documentation still only mentions the panic mode, and that the GDB stub setting is hidden from the regular configuration menu, looks like the stub might not be production-ready yet.

Either way, you can configure VisualGDB to use the stub as shown in the attached file (also add “set serial baud 115200″ to Additional GDB Commands -> Before Selecting a Target), but there are some caveats (e.g. you would need to program the FLASH memory manually first, and connect to it in terminal and press Ctrl-C to trigger a break-in). If anyone can confirm that they get reasonable performance when using the stub, we will happily add streamlined GUI to launch it out-of-the-box.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

We are not aware of any gdb stub for ESP32S3 that would do full debugging (more than analyzing a crashed device without stepping/running it).

You can try asking Espressif for more details.

[support]

Hi,

This is likely caused by a particular combination of settings, and the challenge would be narrowing down the exact settings.

You can start by logging the J-Link GDB server command line and the GDB commands via VisualGDB (View->Other Windows->VisualGDB Diagnostics Console for command lines and VisualGDB Project Properties -> Advanced GDB Settings to enable GDB logging). This should help you reproduce the problem with just command-line tools from Segger, so you can share the repro steps to them and see if they have any suggestions.

[support]

Hi,

ESP32 projects generally have 2 output channels: serial port (typically wired to the onboard USB-to-COM chip) and the application trace. VisualGDB supports viewing both:

• The serial port output can viewed via the Raw Terminal (activated via VisualGDB Project Properties -> Raw Terminal).
• Application trace can be viewed via the semihosting GUI (activated via VisualGDB Project Properties -> Embedded Debug Tweaking).

That said, the ESP-IDF has a relatively complex system of configuration parameters, so you would need to check them to see where the output of a particular project goes.

[support]

Hi,

Thanks for renewing.

For ESP-IDF, the memory layout is taken from the [toolchain directory]\esp32-bsp\bsp.xml file (for old-style toolchains) and from %VISUALGDB_DIR%\Rules\espidf.xml (consolidated toolchain), that was derived from the default linker scripts supplied by Espressif.

You can edit the memory addresses and sizes by changing the MCUMemory elements (make sure you change it for the correct device).

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

Not really sure how VisualGDB could help here. But if you have any ideas, feel free to share them.

[support]

Hi,

This looks like a bug in some of the tools used to program the FLASH memory. If you are using OpenOCD, you can try installing earlier package versions via Tools->VisualGDB->VisualGDB Package Manager. If you are using a different tool, you can try running it manually on different machines to see if there is any pattern.

[support]

Hi,

We have just retested it with ESP-IDF 5.5.1, and it worked mostly fine. The default project template had the MINIMAL_BUILD property turned on, that would prevent the new component from being built, but disabling it fixed it just fine.

We have updated our tutorial accordingly.

[support]

Hi,

Well, googling up “.Net path length limitation” is not the real problem here. The problem is side effects in a system where we don’t control every part.

VisualGDB is an extension that gets loaded into at least 3 different .Net processes: Visual Studio GUI itself, background MSBuild worker, and MSTest runner. Globally changing the manifest for even one of them is almost guaranteed to trigger some unexpected behavior in some other plugin that is loaded into the same application.

So, what we do when it comes to workarounds, is look whether the fix is reducing or increasing the external complexity. Changing a global manifest (so every single MS assembly inside devenv will run under different global configuration than it was ever tested by MS) would be a huge no. Manually copying files under long paths might blow back if another extension (or VS component) tries to enumerate them, and doesn’t handle the paths accordingly. It’s tolerable if we were fixing a major bug (e.g. debugging completely broken for multiple projects), but not worth it for a cosmetic fix.

What we ended up doing (removing the extra copying step) actually reduced the external complexity (each project has now fewer files), so we wouldn’t expect it to break anything else that wasn’t broken already.

Hope this explains.

[support]

Hi,

It’s a good question what to consider a band-aid in this case. All VisualGDB does is copies the files created by CMake under a slightly longer path using the standard .Net copying API. One could argue that a proper fix would be to understand why the .Net framework doesn’t handle this properly, since many other tools, including Visual Studio itself, also heavily use .Net.

Either way, we have recently updated our CMake subsystem to support toolchains coming from vendor-specific VS Code extensions, and were also able to optimize away the extra copying of response files. Feel free to try this build: VisualGDB-6.1.3.5439.msi

[support]

OK, we are not really sure how you managed to get the gnu2b value in the first place (searching ESP-IDF for gnu2b doesn’t find anything, and googling it only finds your post). We would advise double-triple-checking everything to avoid breaking things further.

That said, as promised, we have updated our Clang IntelliSense engine to the latest Clang 21.1. So, it should work with the latest language standards supported by Clang. You can try the new version here:

VisualGDB-6.1.2.5424.msi

Update: the issue could have been related to the old mapping rule that would replace the gnu++23 standard with gnu++2b (as needed by Clang 16.0). Applying that rule to gnu23 would have yielded an invalid value of gnu2b, but then the CMake fix you mentioned would not work because CMake would be outputting gnu23 and the gnu2b would be substituted later.

Either way, the new engine based on Clang 21.1 does not use this mapping, and should work just fine.

[support]

Hi,

This is tricky. This particular error happens when VisualGDB tries to copy the CMake code model to its own cache directory. The original file path is likely just below the MAX_PATH limit, and the one in the VisualGDB’s cache directory is above.

The good fix for this would be to try convincing the CMake maintainers to put a length limit on the code model file names, so the problem wouldn’t happen in the first place.

Another option would be to enable the legacy server mode instead of the file mode via  Tools->Options->VisualGDB->CMake->API for querying CMake state.

We will take another look at the VisualGDB’s logic for reading the model files in about a week, and will see if we can add a better workaround.

[support]

Hi All,

We got VS2026 integration working reasonably well. There are still more tests to run, but this version [VisualGDB-6.1.2.5416.msi] will work much better than the copied Extensions folder.

[support]

Hi,

No problem, you can try this tutorial: https://visualgdb.com/tutorials/linux/

[Author]

Posts