Forum Replies Created
-
Posts
-
Hi,
VisualGDB uses the regular CMake for its projects. You can actually find the sources for the functions like add_bsp_based_library() in %VISUALGDB_DIR%\CMake\embedded.
The motivation behind using the add_bsp_based_executable() was to allow having multiple BSPs per project. A BSP defines compiler flags, include directories, etc., and every executable/library that uses that particular BSP automatically receives these flags.
If you absolutely want to override this mechanism and have your own global flags, you can easily add your own CMake functions either to the project’s CMake files, or to some shared files imported from the projects. E.g. you can see how add_bsp_based_executable() loads the BSP’s CFLAGS, and implement something similar.
Hi,
There are 2 ways to attach to a process from VisualGDB:
- Using the regular Debug->Attach command in Visual Studio. We have a tutorial here demonstrating how to do it.
- You can also configure the project to automatically attach to an existing process instead of launching a new one via VisualGDB Project Properties -> Debug Settings. This way, you can retain other project-specific settings like path mappings, or additional GDB commands.
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.
