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

[support]

Hi,

Sorry, we don’t have a specific tutorial for using Qt with MSBuild and a cross-compiler, although the steps will be very similar – obtaining a build log file and creating GenericGNUTool rules just like you did for the directly compiled project.

If you are not comfortable modifying the .vcxproj file, please try using Raspberry Pi 3 for compilation – its 4-core CPU is fairly fast.

[support]

Hi,

No problem, we will update it in the next 1-2 months and will post an update via our Twitter.

[support]

Hi,

Yes, we have double-checked it with MSBuild and could not get any error (other than VirtualBox issues from trying to access an elevated instance from a non-elevated command prompt). Please try this build, it will list the exact PATH directories it checks and the explicit vagrant location from the settings: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2164.msi

Please double-check the output for typos, extra spaces/quotation marks, UAC-related problems, etc.

[support]

Hi,

Sorry, just editing the .vcxproj file to switch to cross-compilation won’t be sufficient. Instead, please do the following:

1. Create a new cross-compiled Qt project using the QMake project subsystem. This will get all Qt-related tools in sync and ensure they work. Ensure the project builds and starts properly.
2. Create a new cross-compiled MSBuild project. This will get the toolchain profiles and other settings to work (it will also setup IntelliSense).
3. Finally apply the same custom rules to the newly created MSBuild project. This will add support for invoking uic/moc so you can build your project fully automatically.

Let us know if you run into any problems and we will help.

[Author]

Posts