[support]

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?

[support]

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.

[support]

Hi,

Yes, this should be already included in v5.4 Preview 2.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

Hi,

No problem, we have a tutorial on raspicam as well: https://visualgdb.com/tutorials/raspberry/camera/

 

[support]

Hi,

We understand this issue involves many different components, however separating them and running tests on several different configurations is the only way to narrow down the root cause. Without trying another SSH client it would not be possible to know whether the problem is related to the way VisualGDB handles SSH requests, or a general limitation of the SSH server.

[support]

Hi,

No problem. We have added an option to explicitly specify the executable file extensions under Tools->Options->VisualGDB->Common->SSH in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2172.msi

We could also add support for preserving permissions, although in our experience not all tar versions support the advanced options (VisualGDB generates tar archives on-the-fly to upload large file sets), so this might cause more trouble than convenience.

[support]

Hi,

Thanks for checking this. It could be then a limitation of the SSH server. Please try reducing the program to a version that doesn’t depend on graphics (i.e. only uses the terminal API) and check if the problem could be reproduced with SmarTTY. If yes, please also check if any other SSH client (e.g. PuTTY) shows the same behavior.

If this is the case, the issue is on the SSH server side and installing a newer version might help.

[support]

Hi,

Sorry, as the steps are very similar, we don’t have any short-term plans for publishing another tutorial. That said, if you encounter any specific issues while trying to apply the steps from the current tutorial, feel free to post the details here and we will help you resolve them.

[support]

Hi,

Good to know it works. It’s hard to say what part of the build process resets the PATH variable. It did not get reset in our test environment and it could be tricky to track it down, so if the manual location works, we would advise to keep using it.

[support]

Hi,

VisualGDB normally should not override the default behavior for key handling, so most likely this is caused by something else. We can help you narrow it down though.

First of all, are you using a cross-compiler (with gdbserver) or is gdb running directly on Raspberry Pi? Does selecting Debug->Run Without Debugging result in the same behavior as under VisualGDB? If yes, does running the program from SmarTTY also reproduce the problem?

[support]

Hi,

The ID is contained in the toolchain.xml file inside the toolchain directory. Simply ship it together with your toolchain and VisualGDB will handle it correctly even if it’s installed to a different directory on each machine.

[Author]

Posts