Forum Replies Created
-
Posts
-
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.
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).
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
