Forum Replies Created
-
Posts
-
Hi,
We haven’t specifically tested VisualGDB with wayland. In order to get it working, you would need to first find out how to debug it with normal gdb via SSH. Once that works, we can help you configure VisualGDB to replicate that setup.
Hi,
This could be related to a recently fixed bug. Please try installing the latest VisualGDB 6.0R6 and try re-creating the project from scratch.
Hi,
You can use a checkbox in the very beginning of the wizard that allows placing the generated Visual Studio project in the directory of the original project. You can also choose to automatically rename it to match the original project name.
Hi,
No problem, please refer to the following page: https://visualgdb.com/support/callstack
When I load the Arduino framework as a user in VisualGDB for the first time and when creating an Arduino project, it currently downloads automatically a non-functional Arduino framework. But why?
Because Espressif published it as a stable package ready to download. If you install the Arduino IDE and create your first project on the same day as with VisualGDB, it will download exactly the same versions of all packages.
As I mention you should know which one works.
We do that with regular ESP-IDF. A couple of times a year Espressif releases a new toolchain and a new major ESP-IDF update. We quickly test them together, bundle them as a package and release it as a single tested download.
Arduino is much more decentralized with thousands of libraries, cores and packages, so every single day something new gets released somewhere. It’s a great way to quickly put together some proof-of-concept code out of pieces made by others, but it will always involve some troubleshooting and dealing with broken incompatibilities due to the sheer decentralized nature of it. And based on the feedback we get, people often use it for all kids of exotic devices, forks and drivers we never heard about, so limiting it to a handful of verified packages will simply kill most of the use cases.
If you are not comfortable doing it, please use another platform. The STM32 SDKs are rock solid and are additionally tested on our side before each update.
Good to know it works. Most likely, some VS components got corrupt during the installation process, and repairing the VS installation fixed them.
Hi,
No problem, we have a tutorial just for this case: https://visualgdb.com/tutorials/arm/legacy/
Hi,
Thanks for sharing this. This is a leftover from the BSP system layout that used the path explicitly (it can still use it now in some cases like manually overridden per-file settings) and this workaround should indeed work just fine.
If anyone else finds the message too annoying, feel free to post here. If it bothers enough users, we can add a better workaround on our side.
The trouble with the Arduino system is that every vendor (original AVR Arduino, ESP32, STM32, etc) ships their own packages. Often, new package versions fix some bugs from the previous versions and introduce some new bugs. Each of them has their own bug tracker, their own Github repository and their own community. So any work we put into resolving these issues will get completely obsoleted when the next package version comes out. Except, then we would get more requests for help, more issues to fix, and it would quickly snowball to the point where none of the work we do actually improves VisualGDB in the long run, and is quickly obsoleted by another update. We tried it before, we really did, and it’s just not viable, sorry.
What we can reliably offer is convenient GUI and deep integration with VS. You can configure existing package paths and not download anything new. You can choose the framework versions to download. You can decide whether to upgrade or not. You can revert to the old version if the new one is not working. We provide the GUI for all of that, but we cannot take over the maintenance work done by the package vendors. If the latest ESP32 Arduino package has broken debugging on Windows due to some missing libraries, it will remain broken until Espressif releases a fix for it.
As for our builder fork, the only modifications we introduced is accurate dumping of all GCC command lines, so VisualGDB can offer best-in-class IntelliSense that is way more accurate than any other IDE that does not have access to the underlying command lines.
As for the other IDEs, if you can confirm that the same functionality (e.g. debugging) works with another IDE on the same machine with the same versions of all libraries/packages, etc., we can help you configure VisualGDB to match that setup. But we will ask you to narrow it down to specific command lines on your own.
No problem, you can always attach to the stuck process to see what is going on inside it. Just make sure the project used for attaching has physically the same executable than the project that is actually running on the device.
Hi,
The –set argument comes from the way VisualGDB handles the device parameters. STM32CubeIDE generates temporary scripts for each project that set some parameters and reference the original script. Our fork instead takes the –set arguments via command line so you won’t need the temporary files. The exact parameters passed via –-set come from the configuration files themselves (see the #SysprogsConfig lines in stm32_common.cfg). VisualGDB parses them, displays them in the GUI, and then passes the selections back to OpenOCD.
You can work around it by either just reusing the generated script from STM32CubeIDE, or removing the “#SysprogsConfig” lines from the .cfg files, and hardcoding them inside your device script.
OK, we have double-checked everything again.
ST appears to have some glitch with their repository. The OpenOCD binary shipped with STM32CubeIDE mentions a git commit that is not listed on Github and appears to support more devices as well. The Github repository shows the last commit in March 2024, but the git log for the same repo dates it as June 2023.
It looks like this has interfered with our release system, so the last batch of commits was not included in our last binary. We have updated it to match them. If it still doesn’t work, you can simply replace the OpenOCD binary under %LOCALAPPDATA%\VisualGDB with the exact version shipped with STM32CubeIDE. It won’t support some secondary improvements like ultra-low-latency Live Watch, but should work fine otherwise.
Hi,
We have checked the avr_debugger repository and it looks like they do support Arduino. However, you also need to flash a custom bootloader and patch the original Arduino core (note that the patches appear to be 7 years old) in order to use that.
If you can get it working via command line to the point where you can debug everything by running gdb manually, we can help you configure VisualGDB to match that setup.
CMake uses its own logic for deciding how to build each individual file, however most of it is configurable. Specifically, you can pass assembly-specific CFLAGS by using the $<COMPILE_LANGUAGE:ASM> expression in bsp_compile_flags. You can find some more examples of it in the %VISUALGDB_DIR%\cmake\embedded\bsp.cmake file.
If you cannot get anything working with CMake, you can try using MSBuild. There VisualGDB is in direct control of each compiler invocation, so you can clearly specify which tool to use in each specific case, and what arguments to pass. That said, MSBuild projects rely on a lot of legacy parts from Visual Studio itself, and are somewhat less streamlined than advanced CMake projects.
