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

[support]

Hi,

No problem and sorry for the confusion. The “programmed separately” mode will still reserve the memory for the softdevice (it will be filled with 0xFFs and won’t contain the actual softdevice firmware). You will still need to program the softdevice into the FLASH memory before your softdevice-enabled firmware can run (if you are not using a softdevice, select “none” instead of “programmed separately”).

If this doesn’t help, please let us know what you are trying to achieve and we can easily release another hotfix that will enable your use case – after all the goal of VisualGDB is to make your development experience as seamless as possible.

[support]

Hi,

No problem and sorry for the inconvenience. As VisualGDB mostly focuses on debugging C/C++ code, our Python projects are based on the same underlying project mechainsm, so they will indeed only show Python files in the templates. The workaround is very simple – just create any type of file (e.g. .cpp) and change the extension to .py. Both Visual Studio and VisualGDB will understand this and you will be able to use the file as a part of your project.

[support]

Hi,

Please try installing VisualGDB 5.4 Preview 2 – it resolves several cases of the spurious “regenerate MSBuild rules” message.

Regarding the static libraries, if you are using MSBuild, you can use the “Exported Settings” page of VS Project Properties – simply add your additional library names to the “exported library names” field and VisualGDB will automatically add them to the final executable you are linking.

If you are using QMake, this might require writing custom build rules. You can try the suggestions described on this page, however using MSBuild should be generally easier as we have designed the “exported settings” mechanism specifically for this case.

[Author]

Posts