Forum Replies Created
-
Posts
-
Hi,
This looks like a problem inside the Segger gdb stub. Please check with Segger support whether they have a fix for this.
Hi,
Thanks for letting us know. The FetchContent module looks new, so most likely it was not yet available in the version used in our build. This should get fixed automatically once we update our pre-built CMake from the latest sources.
Hi,
Sorry for the delay. We have added experimental support for relative paths in CustomToolchain.xml (using the $(ToolchainDir) syntax) to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2185.msi
Let us know if it works for you (you will need to delete the CustomToolchain.xml file and re-import it in order to get the correct path syntax).
Hi,
Thanks, this is a known limitation of the “del” command. As a workaround, please try setting USE_DEL_TO_CLEAN := 0 in your <config>.mak file (if your toolchain as the rm tool), or simply edit the Makefile to use backward slashes or specify quotes (only in the clean command line).
Hi,
This is by design. VisualGDB 5.3 and later does not store the toolchain location anywhere in the project files, letting you build your projects without modifications on computers with different toolchain locations. When building with VisualGDB, the TOOLCHAIN_ROOT variable is computed dynamically and set before invoking Make. If you want to run Make manually, you need to set TOOLCHAIN_ROOT explicitly (or hardcode it in the Makefile using the ?= syntax if you are OK with storing it there).
Hi,
Thanks for the screenshots. It looks like a known issue. Unfortunately the ST-Link v2 has a bug that prevents it from reporting its USB serial number the way OpenOCD can read it. This has been fixed in ST-Link v2.1 (that is installed on most newer boards). Please either try upgrading your board, or check if there is a firmware update that will turn your ST-Link into v2.1.
You can also try locating and applying ST’s patches to OpenOCD that resolve this, however in our experiments they introduced strange side effects, so we ended up not including them in our OpenOCD build.
Hi,
Sorry for the delay, we have been receiving a larger amount of inquiries than usual. We will respond to your support ticket within the next 24 hours.
Hi,
Please ensure you have the “USB devices” not “Debug methods” selected on the Debug Settings page of VisualGDB Project Properties. Otherwise VisualGDB won’t be able to tell apart between the 2 instances.
If this still doesn’t help, can you confirm that the “Test” button works for both projects? If not, what is the error output?
Hi,
No problem, we could add a workaround for this. Please let us know the VisualGDB build number (from the About window) so that we could pinpoint the exact location of the crash.
Hi,
Most likely you have not installed the WinUSB driver for the interface #0 of the debug adapter. Please download and start UsbDriverTool, locate the interface 00 of your USB JTAG cable and install the WinUSB driver for it. This will get OpenOCD to recognize your device properly.
Hi,
Sorry for the delay. We have pinpointed and fixed this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2183.msi
You may need to restart your Raspberry Pi in order to reset the old cached files.
Hi,
This might be caused by some errors in the manual .vcxproj file edits. Please try creating a new non-Qt project for the same target machine and the same toolchain and check if it shows the same “Regenerate MSBuild rules” message (you may need to restart VS to get it reproduced). If it doesn’t, please try comparing both .vcxproj files and try removing some of the edits to see if any of them fixes the behavior.
The snippet you mentioned for adding the header/user interface files looks correct. As long as the PropertyPageSchema item is included properly, this should work.
Hi,
Sorry, this is actually by design – VisualGDB manages toolchains independently from projects (e.g. creates and maintains MSBuild property files, IntelliSense setup files, etc), so that multiple projects can reuse the same settings. As a result, it needs to know the absolute toolchain location without knowing the project location.
Specifying $(ProjectDir) in the toolchain XML file will get this syntax copied to MSBuild files, so most of the build will likely work, although all advanced functionality (like sysroot synchronization, or IntelliSense file caching) may break as VisualGDB expects the location to be project-independent.
Please note that the project/settings files won’t hardcode any toolchain directories – instead they contain the toolchain ID and version, so you can easily share them between multiple computers with different toolchain directories. If this doesn’t help, please let us know what you are trying to achieve and we will try to suggest a configuration that will work.
Hi,
No problem, we have a tutorial on raspicam as well: https://visualgdb.com/tutorials/raspberry/camera/
