Forum Replies Created
-
Posts
-
Hi,
VisualGDB looks for RTOS-specific symbols (tables of all tasks, etc) in the debugged image. As long as they are present, it automatically loads the RTOS plugin regardless of how the image was built.
Splitting the code into 2 images where RTOS and the actual payload is rather uncommon, so VisualGDB does not support this automatically. You can try using some external tool to merge them back into one ELF file and debug that one, but it could be tricky.
Hi,
Yes, they are only supported on ARM devices with background memory access. RISC-V is slowly becoming more popular, so we may eventually port the real-time analysis frameworks there, but currently they only work with ARM.
That said, Live Watch does not require any special frameworks and will work with any CPUs that support background memory reads.
Hi,
The GNU Make build system is very old, limited in many ways and does not support many advanced features directly. In theory, you should be able to get them working by patching the Makefiles, however we do not have any examples of it and are not planning to add one.
For new projects, please consider using Advanced CMake or MSBuild. Both work much better than plain GNU Make and have better integration on the VisualGDB side as well.
Hi,
It looks like an issue between OpenOCD and a particular board. We do not know what is causing it – both the ESP32 OpenOCD port and the board are provided by Espressif.
Our best advice would be to first get it working via command line (i.e. being able to program FLASH on the same board with OpenOCD manually). When this works, we can help you configure VisualGDB to match the OpenOCD command line that worked.
Hi,
Please refer to this page for a detailed explanation of ESP-IDF integration and troubleshooting tips.
Our OpenOCD forks (including the fork of their fork) contain a couple of minor changes (e.g. commands for low-latency memory reading used by Live Watch and tracing), so we usually just apply those on top of the original sources from either fork, and rebuild everything. Without the sources, this won’t work.
Either way, you can manually just copy the binary from STM32CubeIDE on your side. It should work the same way.
Hi,
Based on what we’ve seen, ST hasn’t published the sources for their latest OpenOCD. We opened an issue on Github for it, but got no reply. You can try contacting them directly – maybe you’ll get better luck.
Hi,
Sure, 2 BSPs with different aliases should work.
If you have trouble locating the properties, please attach an UNCROPPED screenshot of the Visual Studio window showing the Solution Explorer and we will point it out.
Hi,
VisualGDB doesn’t do anything special with Qt. It merely runs gdb via SSH using the command line shown in the GDB session window. If it affects the Qt functionality, it’s something between Qt and GDB and is not a VisualGDB-specific issue, sorry.
Hi,
Unfortunately, it is hard to say anything specific based on the information you provided.
Our best advice would be to try creating a new similar project from scratch and check for any errors along the way. If the new project works and the existing ones do not, you can try comparing the .vcxproj files between them, and temporarily copying the working .vcxproj file into the broken project or vice versa to see if it affects the issue.
Hi,
If debugging works on the host, you can configure VisualGDB to run the gdb on the target. If it still doesn’t work, you can check the gdb log on the VisualGDB side and the gdb log on the Qt Creator side, making sure the commands issued by VisualGDB (e.g. paths used in breakpoints, path to the executable, etc) are the same as the commands issued by Qt Creator.
Hi,
Thanks for sharing this. We finally received our RP2350 board, tested it out and released an updated OpenOCD package that supports RP2350 out-of-the-box. Feel free to update via VisualGDB Package Manager.
Due to reasons unknown, the Raspberry Pi developers combined the RP2350 support with an unknown subset of other commits from the OpenOCD repository into a single large commit, so it is not easy to fully port it into the mainstream OpenOCD. So, our package currently includes a separate OpenOCD executable for RP2350 based on the Raspberry Pi fork (openocd-rp2350.exe). VisualGDB will handle it transparently, as long as you select one of the rp2350_xxxx.cfg scripts.
As for VisualGDB 6.0R3, you need to select the Pico 2 device manually (the auto-detection logic cannot distinguish Pico 2 from Pico 1 yet), but an upcoming update to VisualGDB will resolve it.
Hi,
The HAL configuration file is used by both the application and the HAL itself. Hence, adding the include directory for just the application won’t be sufficient.
Instead, you would need to add it for the entire BSP using the VS properties for the BSP item in Solution Explorer or using the bsp_include_directories statement.
Hi,
This is somewhat of a known trade-off. Visual Studio requests a lot of background information from VisualGDB quite often, so it somewhat limits how much details about the project it normally collects, and tries to cache as much as possible.
That said, detecting changes to host aliases and using the correct deployment directory for custom shortcuts is doable without too much slowdown. Feel free to try this build: VisualGDB-6.0.103.5211.msi.
