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

[support]

Hi,

This looks like a bug fixed in the v5.4 Preview. Please try installing this version and create the project again.

[support]

Hi,

The Atmel studio uses a proprietary debug engine that is indeed better optimized than the open-source Avarice tool (especially if you are using a VM with USB virtualization), however unfortunately it’s beyond our capacity to develop and ship a custom low-level debug engine just for AVR devices, so we have to rely on the open-source tools.

Our best advice for improving performance would be to enable the timing view in the GDB Session window and check the commands that VisualGDB runs. If most of the time is spent querying call stack, variable values, etc., closing the corresponding VS windows will dramatically improve the performance.

[support]

Hi,

As the environment variables like PATH are set per-process and are inherited from the parent process, sometimes some unexpected configuration settings interfere with them.

Please double-check the PATH value from the same command-line prompt where you run MSBuild (also ensure it’s the same user account that runs VS, as the manual vagrant location is set per-user).

[support]

Hi,

Thanks for pointing this out, looks like our bug. We have released an update to the Nordic BSP resolving this. Please update via Tools->VisualGDB->Manage VisualGDB Packages (you will need to regenerate the MCU-specific files in order to get the project to build).

[support]

Hi,

Sorry, combining Qt-based projects with MSBuild-based libraries is not supported directly, but there are a few workarounds.

The recommended approach would be to switch your Qt project to use MSBuild as described in this tutorial. It involves a few extra steps, but will give fine-grain control over various build settings, will result in faster builds and will allow compiling individual files to quickly check for errors.

Another option would be to create a Qt application project and manually edit the .pro file to turn it into a library project as described here and then edit the .pro file of the main project to link with the output of the library project. Let us know if you need further help with this.

[support]

Hi,

This might be caused by a problem that was recently solved in our development branch. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2157.msi

[support]

Hi,

The stm32.props file is located in the main project directory (same directory as the .vcxproj file). Please note that the file name might be different if you are using a different MCU family. Searching for *.props in the project directory should normally help.

[support]

Hi,

OK, we have improved the ESP-IDF include file handling in the upcoming Preview 2. We still have a few minor issues to polish before releasing it officially, but if you don’t want to wait, feel free to try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2157.msi

[support]

Hi,

Thanks for the detailed feedback, we really appreciated it. Turns out we missed a few corner cases with absolute include paths and combinations of source/header files for recently added components.

We have fully resolved all those issues (and a bunch of other ones discovered via deeper testing) in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2157.msi (you would need to re-create your project, or at least remove and re-enter the include directories in order to get them stored properly).

We have also added the rename and remove commands to context menus (they were already supported in Preview 1, although only worked via keyboard shortcuts like F2 and Del). Thanks for pointing that out.

%USERPROFILE% should actually work as long as you use the GNU Make syntax for it: $(USERPROFILE), not ($USERPROFILE). If it doesn’t, let us know and we will investigate.

If you have any further feedback, or run into other problems, please do not hesitate to contact us again – we appreciate all feedback as it helps us make our products better.

[support]

Hi,

As it was released very recently, it hasn’t been fully scheduled on our side yet, but 1-2 months could be a reasonable estimate.

[support]

Hi,

Sorry, the way test frameworks are currently implemented requires referencing them directly from each application project. This will let VisualGDB run some post-processing on the ELF file in order to discover and handle test cases and this won’t work for static library projects.

If you absolutely want to build the test framework as a static library, please try adding the related sources (and specifying build flags) manually to the project, then reference the test framework from the application project file and manually remove the references to the test source files from it.

[Author]

Posts