Forum Replies Created
-
Posts
-
Hi,
Sorry for your disappointment. We do not have a toolchain for Trixie yet, hence the warning about lsb_release. You can try downgrading to the Bookworm SD card image (the compatible versions are listed here), building the code directly on Raspberry Pi, or using WSL with the Raspberry Pi’s own toolchain (if they provide one).
We have never encountered ld getting stuck forever on a hello world project. That said, if you ignored the lsb_release warning and resynchronized the toolchain’s sysroot, you would end up with a combination of tools and libraries that was never meant to work together, and that could result in completely unpredictable behavior.
If you are not sure, please try completely deleting the toolchain, and starting from a clean SD card image (make sure it matches the toolchain).
Hi,
VisualGDB’s CMake framework uses regular CMake commands. You can find a detailed reference of them here: https://cmake.org/cmake/help/latest/manual/cmake-commands.7.html.
That said, we had to handle a lot of corner cases to make sure everything works out-of-the-box, so if you would like to have your own parallel system, you will likely have to do a lot of research and troubleshooting.
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.
