Forum Replies Created
-
Posts
-
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.
Hi,
Please refer to the ESP-IDF documentation for more information about components.
If you are curious about what exact files get edited when you change a particular setting, you can follow the steps below:
- Make a backup of the project, or commit it to Git.
- Change the setting and reopen the solution to make sure it is saved.
- Compare the old and the new version of the project using an external diffing tool.
Hi,
No problem. First of all, please try this build: VisualGDB-6.0.103.5206.msi. It fixes the BuildHost/DeployHost variable behavior and adds a height limit to the custom action list.
We also added a new command for deploying the output of the startup project (and its dependencies) without debugging (Debug->Deploy Project Output).
If you would like to combine it together with debugging the C# code, you would need to use a 3rd-party macro extension to set the startup project to the VisualGDB one, run the deployment command, set the startup project to the C# one, and finally launch the debug session. The DTE name for the “deploy project output” command is Debug.DeployProjectOutput.
If you would like to deploy the .so files and start debugging the mono process, the easiest way would be to define a dummy executable that is linked against all the .so files (so VisualGDB will treat them as dependencies and will deploy them), and then override the gdb/gdbserver command lines to actually debug mono instead of the dummy executable.
If you would still like to run the VisualGDB custom shortcuts programmatically, we can modify the DTE command handler on our side to accept the shortcut number (or name) as a parameter, if you have a convenient way of running custom DTE commands.
Hi,
No problem, we have made the $(TargetPath) check optional in this build: VisualGDB-6.0.103.5206.msi. It also fixes the BuildHost/DeployHost variable behavior when using aliases.
That said, using the mono path inside sysroot should be the way to go. If the gdb machine has a different architecture than the target machine, the /usr/bin/mono executable could give GDB all kinds of incorrect hints, resulting in weird glitches across the board.
