[support]

Hi,

OK, we have added an option “Don’t activate GDB Session window” under Tools->Options->VisualGDB->General->GUI in this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.13.1881.msi

The Live Variables tool window should normally appear close to the ‘Output’ window. Either way, if you keep the window open, but put it in the background (i.e. behind any other window), it should stay in the background and not re-appear.

[support]

Hi,

Thanks for the link. Looks like you are using the ‘VisualGDB’ platform for non-MSBuild projects. Unfortunately this is not supported (as VisualGDB internally uses the platform name to distinguish between MSBuild and non-MSBuild configurations). We have added a warning for this in the upcoming v5.3R4 build.

To fix this, please rename the ‘VisualGDB’ platform in your project files to ‘x86’ or ‘Win32’ (depending on the VS version you are using).

We have also noticed that you are using CMake. VisualGDB 5.3 comes with a very powerful Advanced CMake Project Subsystem that basically creates a 2-way mapping between CMakeLists.txt files and the Solution Explorer (see this tutorial). We would advise switching to this subsystem (VisualGDB supports importing Embedded CMake projects) as it provides much better user experience with CMake.

[support]

Hi,

This could happen if your firmware was interfering with the SWD pins or power states, hence preventing the debugger from attaching. Please try setting the “connect under reset” flag in VisualGDB Project Properties -> Debug Settings.

[support]

Hi,

Looks like you are trying to create a project in a directory that does not have write permissions. Please try creating it in a different location or run Visual Studio as administrator.

[support]

Hi,

The GDB session window gets activated during the launch of the program to show FLASH loading progress and other information. We can add an option to not explicitly activate it if you believe this would be more usable.

Regarding other windows, this could be caused by a corrupt .suo file. Please try closing the solution and deleting the .vs folder.

[support]

Hi,

The RobotLib.vgbsettings file looks wrong (it looked like an empty .vcxproj file); we also did not see your actual .vcxproj file. Please try archiving all project files (except for the actual .c/.cpp/.h files) and either attach them here or send them via our support form so that we could have a look.

[support]

Hi,

Sorry for the confusion, Include Search Path is the correct option.

We have rechecked the behavior for the manually added directories and managed to reproduce and fix the issue. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.13.1878.msi

[support]

Hi,

Unfortunately this is not supported out-of-the-box as different devices often include different SDK files (e.g. STM32F4 SDK vs STM32F7 SDK). You could, however, achieve the same effect manually in one of 2 ways:

• Convert the project to a stand-alone one, then remove MCU-specific macros and include directories from the first page of VisualGDB Project Properties and move them to the per-configuration “MSBuild Settings” page. Then create another configuration and edit the settings there.
• Create 2 VS projects targeting different devices and a shared project with your actual code. Reference the shared project from both binary projects.
• Create 2 versions of stm32.props file for both devices and modify the .vcxproj file to explicitly include one of them based on the configuration name (VisualGDB would overwrite the original file if you try changing MCU configuration though).

Let us know if you need any further details.

[support]

Hi,

Thanks, we have confirmed your support status.

The problem happens because your code includes headers that declare u8g_InitComFn() and the other functions, but your project doesn’t include source files (.c or .cpp) that define those functions. Please search the sources of your library for definitions (not declarations) of the missing functions and add them to your project.

We also have a detailed tutorial showing how to troubleshoot this type of problems here: https://visualgdb.com/tutorials/tips/externc/

[support]

Hi,

Thanks for checking this. It could be a motherboard bug or a driver bug then. If it works reliably on a laptop, we would simply recommend using the laptop then.

[support]

Hi,

If killing OpenOCD via task manager doesn’t work, this looks like a USB driver/controller bug. Please try using a different USB port or a different computer. Also if you are using a VM, please try running it on real hardware instead as USB virtualization is sometimes buggy.

[support]

Hi,

Thanks for clarifying this. The common settings (like tab sizes) are unfortunately managed by the VS language service mechanism, so they have to be separate. All advanced formatting settings that come from VisualGDB (like indentation for classes/namespaces/functions) are actually inherited from the regular VC++ settings.

We understand this is annoying, however as the workaround is relatively simple (changing a very small set of options once), we don’t want to go hacking the language service internals and risk breaking something on a higher scale, sorry.

[support]

Hi,

The screenshots look OK, so it’s hard to say what is causing this. You can try holding SHIFT while right-clicking on the project – this will force all VisualGDB menu commands to appear.

Deleting .vgdbsettings files unfortunately won’t help as this will lose all VisualGDB settings associated with the project. Re-creating the project via the wizard and comparing the .vxcproj and .vgdbsettings files via a diff tool might help through.

We understand this is annoying and we will try to help you resolve it ASAP, so please follow the steps below to isolate it:

• Can you locate a specific project that fails to upgrade? If yes, what happens if you move add it to an empty solution (so that the solution will only have 1 project)?
• If the project still fails to upgrade, please locate a similar project that works, add it to another empty solution and double-check that it works. Then compare the .vxcproj files and .vgdbsettings files for the working and non-working project. If you don’t see anything out of the ordinary, please attach the files here (or send them via our support form) and we will check for common issues.

[support]

Hi,

Please try updating to the latest Nordic BSP based on SDK 14.0. It contains a few bugfixes, so it might simply fix this as well.

If it doesn’t help, please try building the project using Nordic command-line tools. You can do this by updating the <Nordic SDK>\components\toolchain\gcc\Makefile.windows as follows:

GNU_INSTALL_ROOT := E:/sysgcc/arm-eabi/bin/
GNU_VERSION := 6.2.0
GNU_PREFIX := arm-eabi

Then go to the directory of a sample project (e.g. examples\ble_peripheral\ble_app_hids_mouse\pca10056\s140\armgcc) and build the project by running “make”.

Finally first try debugging your regular VisualGDB project so that the softdevice is programmed, then replace its ELF file (without extension) by the .out file from the manually built project and try debugging again (select “do not rebuild” so that VisualGDB doesn’t rebuild its project). If the problem is also reproduced with the original Nordic firmware, it might be an incompatibility between your SDK and your device (in our experiments devices bought a couple of years ago did not work anymore with SDK 12.0 and simply buying a newer revision of the board solved the problem).

If the original Nordic example works, but the same example built with VisualGDB fails, it is definitely our bug and we will definitely fix it once we can reproduce it (or once you could run a few quick tests on your device that will pinpoint the difference).

[support]

Hi,

Those paths should be internally stored as relative paths. You can double-check it via VS project properties (not VisualGDB Project Properties) -> NMake -> Additional Include Directories.

VisualGDB applies a few internal transformation to the paths when storing them to allow portability across different machines, so the displayed paths are shown as expanded full paths to avoid confusion.

[Author]

Posts