Forum Replies Created
-
Posts
-
OK, we have added special handling for symlinked directories to this build: VisualGDB-6.1.5.5477.msi
The only caveat is that go-to-definition (F12) and find references (Shift-F12) will always open the actual file locations, so you may end up with 2 copies of the same file open. All other functionality (syntax highlighting, outline, etc) now works the same way for both symlinked and actual physical paths.
Hi,
Thanks for reporting this. Looks like the new Clang indeed handles the symlinked files differently. We will run a few more experiments and will publish a hotfix in the next couple of days.
The sysroot synchronization only makes sense if you are using a cross-toolchain (with its own copy of sysroot). It is not needed when building directly on the device.
Hi,
Please make sure you are using the latest VisualGDB 6.1 and not the older version. Depending on your VS installation mode, you may need to uninstall the older VisualGDB first.
Looks like you are still trying to use our toolchain that will not work with your target OS. Please try configuring VisualGDB to build the projects directly on the device instead.
You can try using the setup shown in this tutorial. It should work very similar to your current setup.
Hi,
It should work, as long as your OS has gcc/gdb, or you have a compatible cross-toolchain. As long as your can figure it out for your custom OS, VisualGDB will work just fine.
Hi,
This looks like a glitch with the Espressif’s servers. We have just tried doing a clean installation of the latest ESP32 package, and it worked out-of-the-box without any problems.
Please try fully resetting your Arduino packages by deleting the root directories (we recommend checking the locations via Tools->VisualGDB->Manage VisualGDB Packages->Arduino and MANUALLY deleting the root directories (e.g. C:\Users\<user>\Documents\ArduinoData) to ensure there are absolutely no leftovers left).
The error message also looks a bit off. Normally, VisualGDB should handle the path-too-long errors and just show a summary of the files it could not install. You can try enabling View->Other Windows->VisualGDB Diagnostics Console before you reinstall the packages, and then check if it contains more details (e.g. each path and a stack trace for the exception).
Hi,
The VS2026 support has been added to the 6.1 version. You can download the Beta 4 from the usual download page.
Hi,
If you are only trying to troubleshoot the initialization error, you should normally not need this. Once you press F5, VisualGDB deploys the program and attempts running it. Once it exits with code 129, it still remains deployed as if the debugging was never launched. So, you can run it manually and see what is going on (most likely some dynamic libraries are missing).
If you are trying to do something else, please let us know more about what you are trying to accomplish, so we could suggest the best way to do it.
Hi,
VisualGDB is merely a GUI around the command-line tools from Espressif (in particular, OpenOCD). So normally, all devices supported by it should work out-of-the-box.
If not, please make sure you can get it working by running OpenOCD manually (see the instructions on the Espressif’s website). As soon as you get it working, you can select the same OpenOCD scripts in VisualGDB debug settings, and it should work the same way.
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.
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.
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.
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.
