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

[support]

Hi,

This might be caused by some internal changes in the Nordic SDK. As the SDK comes directly from Nordic, its contents are outside our control, however we can help you understand what is causing this and find a possible workaround.

Please create a separate project using each SDK version and run “arm-eabi-objdump -h <ELF file>” on each of them. Then compare the dumps using a diffing tool (e.g. KDiff3). Most likely you will observe one of the following:

1. The new file contains more sections than the old file and the new sections contribute to the footprint increase (note that only the sections marked with ALLOC actually consume device memory). Those sections were introduced in one of the recent SDK versions and you might be able to disable them by excluding some source files (refer to Nordic documentation for details).
2. The softdevice section is considerably larger. This should not normally happen, so let us know the old/new sizes if you observe it and we can double-check.
3. The regular .text and .data sections are larger (most likely). This comes from extra functions added to the SDK and can be narrowed down by loading both binaries in Embedded Memory Explorer and comparing symbol sizes/names. Again, you might be able to exclude some of the new code by disabling the corresponding configuration defines, or commenting out support for cases that you don’t need.

Hope this helps. If not, let us know your findings and we can advise you further.

[Author]

Posts