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

[support]

Hi,

Thanks for checking this. If avarice works from command line, but not with normal VisualGDB settings, it might be caused by some command line option (e.g. programming the FLASH). Please try comparing the manual command line with the command line shown in Visual Studio when launching the debug session (you can also see the command line via View->Other Windows->VisualGDB Diagnostics Console).

If the command line arguments are exactly the same, does switching VisualGDB debug method to “custom gdb stub” and hardcoding the command line change anything?

[support]

Hi,

You can update to any mbed version supported by VisualGDB (i.e. verified and repackaged by us) via Tools->VisualGDB->Manage VisualGDB Packages. The latest repackaged version so far is v5.6.3r3.

Once we release a package for 5.7.3, VisualGDB will automatically detect this and suggest updating it.

[support]

Hi,

Thanks for the screenshots. In v14.2 the setting was moved from a separate checkbox to another entry in the “Softdevice” combo box. Simply select “S132 (Programmed Separately)” for the same effect.

[support]

Hi,

No problem. If you are planning to debug some Linux-specific issues that involve custom gdb commands, you can use the GDB Session window in VisualGDB – it will let you run custom gdb commands as if you were using the regular command-line debugging experience and will automatically translate common commands (e.g. for setting breakpoints) to corresponding VisualGDB actions, so you can easily follow Linux-specific tutorials for those libraries with the full convenience of Visual Studio.

[support]

Hi,

Yes, please follow our OpenCV tutorial here: https://visualgdb.com/tutorials/raspberry/opencv/

[support]

Hi,

It should be still possible with 14.2. Simply select “No softdevice” or “Softdevice (Programmed separately)” on the first page of VisualGDB Project Properties.

If this doesn’t work, please attach a screenshot of the corresponding property page showing the expanded “Softdevice” combo box so we could check what is going on.

[support]

Hi,

Thanks for sharing this. It is indeed the correct way to specify those flags.

[Author]

Posts