[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.

[support]

Hi,

You might be using an older VisualGDB version then. Please ensure you update to v5.3 (or v5.4 Preview) and also install the latest Segger package via VisualGDB Package Manager.

[support]

Hi,

No problem. All MSBuild-specific rules are located in the <VisualGDB directory>\MSBuild folder, although we generally don’t recommend patching them as updating VisualGDB will override your changes. Instead you can add custom rules files inside your source checkout and reference those additional files from your projects, combining VisualGDB rules with your custom rules.

[support]

Hi,

Thanks for sharing the error message. It looks like some MSBuild rules might be overriding the PATH variable (enabling verbose msbuild output might help diagnose it) and the explicit location is not working because it specifies the directory name, not the full path of vagrant.exe. You can simply change it to C:\HashiCorp\Vagrant\bin\vagrant.exe and it will work.

[support]

Yes, please use the solution described in this thread: https://sysprogs.com/w/forums/topic/configure-segger-j-link-to-target-specific-device-in-scan-chain/

[Author]

Posts