Forum Replies Created
-
Posts
-
No problem. Please try the following:
- Start a debug session with VisualGDB and take a note of the debug port used by OpenOCD.
- When VisualGDB reports that it cannot connect to the target, press the “ignore” button. Do not stop the debug session, so that VisualGDB keeps OpenOCD running.
- While OpenOCD launched by VisualGDB is still running, try manually running gdb and connecting to the target.
If the manually initiated connection works, please double-check your firewall settings and try disabling it, as it might be specifically blocking the Visual Studio process and gdb launched by it.
If the manually initiated connection doesn’t work, please try ending the debug session in VisualGDB and immediately running OpenOCD with the same command line (please use the complete command line including all environment variables from View->Other Windows->VisualGDB Diagnostics Console).
Please let us know your findings and we will advise you on further diagnostic steps.
Hi,
This could indicate a network/firewall issue. Please try doing the following manually:
- Run OpenOCD on Raspberry Pi
- Run GDB on Windows
- Manually run the “target remote” command in GDB.
If the connection doesn’t work, please try changing the port to a lower value (e.g. 3000).
You can change the port number used by VisualGDB by setting the PreferredGDBPort element in the .vgdbsettings/.vgdbcmake file to a non-zero value. It will override the default logic of picking a random unused port.
Hi,
VisualGDB follows the project structure set by the STM32CubeMX generator, placing all files generated by it (including the main one) into the BSP library, and the user-added files directly into the executable.
As the executables and the BSP libraries are defined in different CMake targets, they have different sets of settings (executables inherit the settings from the BSP libraries) controlled by CMake statements like target_include_directories(). Editing various settings via GUI ultimately generates one or more CMake statements and has exactly the same affect as if these statements were added manually.
Based on the description you provided, you ended up with a set of target_include_directories() statements that do not match the actual targets. The easiest way to troubleshoot it would be to double-check what statements got added to CMakeLists.txt files. If they reference incorrect BSP names (see the find_bsp() statements), you can simply adjust them manually by editing the CMakeLists.txt file. If you can confirm that VisualGDB consistently generates invalid statements in some cases and can share the steps to reproduce the issue we should be able to fix it. Otherwise, simply patching the generated statement manually should work fine as well.
You can read more about CMake targets and how VisualGDB handles them here: https://visualgdb.com/documentation/projects/cmake/
Hi,
As per the documentation page, running OpenOCD remotely is supported starting from the Linux edition. If you are using the lower Embedded edition, you can always upgrade it here: https://sysprogs.com/splm/mykey.
If the feature worked earlier, it was likely during the trial period which is equivalent to the highest available Ultimate edition.
Hi,
Please do check the page we linked in the previous reply – it shows the exact setting for this exact behavior.
Hi,
You can also try using DWARF 5. It is considerably different from DWARF4 and might work around the issue. Another thing to try would be using GDB indexes.
You can troubleshoot the slow gdb response by running the “set debug remote 1” command and checking whether the delay comes from the target answering GDB requests (e.g. OpenOCD) or gdb itself (i.e. happens between a reply and the next request).
Hi,
Our fork of OpenOCD mainly focuses on improved integration with VisualGDB (e.g. faster memory reading API for VisualGDB to use) and does not duplicate any of VisualGDB’s features on its own.
Hi,
Please refer to the following page for more details: https://visualgdb.com/documentation/colors/
Hi,
Sure, you can always click the “select a third-party toolchain” button to import an arbitrary toolchain. VisualGDB will create a Toolchain.xml/CustomToolchain.xml file either in the toolchain directory or under %LOCALAPPDATA%, where it will store the toolchain properties. You can then manually edit the file to customize various settings (e.g. add hardcoded CFLAGS). See this page for a detailed explanation.
Hi,
The OpenOCD implementation of semihosting is rather unreliable, hence VisualGDB provides its own one. Naturally, it will only work when using VisualGDB for debugging.
If you are able to connect (and successfully use) gdb to OpenOCD when you run it manually, please share the following:
- The exact command lines from OpenOCD and GDB from the manual debug session that works.
- The OpenOCD and GDB command lines shown by VisualGDB/VisualKernel. You can find the OpenOCD command line in OpenOCD window in Visual Studio during a debug session. The GDB command line is shown in the GDB session window.
- A screenshot of the exact error message you get with VisualGDB/VisualKernel.
Hi,
If OpenOCD generally doesn’t work with your hardware, running it with VisualGDB/VisualKernel won’t automatically resolve the OpenOCD issues. If this is the case, please consider asking in the OpenOCD or Raspberry Pi community.
If you can get OpenOCD/gdb working when you launch it manually, we can gladly help you configure VisualGDB/VisualKernel to use this setup for debugging.
Please refer to the following page for a detailed description of MSBuild project files: https://visualgdb.com/documentation/projects/msbuild/
Hi,
In general, ignoring the .vs, .visualgdb and build subdirectories should work for most project types, however you may need to ignore additional file types depending on your project type. You can find the detailed description of different project types and related files here.
If you encounter file types that are not covered by the documentation, feel free to let us know and we will update it accordingly.
Hi,
This looks like a bug in the gdb executable, that is typically triggered by some constructs in the debug symbols. You can try working around it by:
- Using a different gdb executable from an older or newer toolchain.
- Explicitly selecting another DWARF version in gcc settings (e.g. -gdwarf-4).
- Stripping the debug information from the object files you are not intending to debug.
