[support]

Hi,

VisualGDB supports the .natvis files on all supported VS versions as long as the files are explicitly added to the project in Solution Explorer.

You can check the View->Other Windows->VisualGDB Diagnostics Console for messages explaining the .natvis file search.

[support]

Hi,

Our latest STM32 BSP includes many of the ST examples, so you can simply select “STM32Cube examples” on the sample selection page of the VisualGDB project wizard and pick a sample project to import.

If you want to import a different project, you can use the “Import existing project” option in the wizard, but you would need to manually locate and specify various build settings (e.g. include directories and preprocessor macros).

[support]

Yes, we have just released the new toolchain.

Note that it requires a few extra configuration steps, so please follow the updated ESP32 tutorial to get started with it.

[support]

Hi,

You can try installing the WinUSB driver for the virtual J-Link device and using OpenOCD to debug it (FLASH programming may be less reliable and may require selecting a script manually), although the debugging experience will be less convenient than with the Segger software.

 

[support]

Hi,

Sorry, an overnight fix on Sunday night is a bit beyond our capabilities.

We have investigated this and confirmed a bug in our register definitions for Tiva devices. We have updated our BSP with the correct definitions.

You can install the latest BSP via Tools->Manage VisualGDB Packages.

[support]

Hi,

Yes, sorry about that. The STM32 BSP comes with different versions of the cmsis_os.h and the VisualGDB header discovery does not go deep enough to validate them.

Normally if you add references to FreeRTOS via the Embedded Frameworks page, VisualGDB should set the correct include directories automatically and you won’t need to fix anything manually.

[support]

Hi,

No problem. The shared library should do as well, as long as it is always present on your target system.

[support]

Hi,

This could happen if your toolchain is not compatible with the deployment computer. Please examine the error log shown by VisualGDB for further clues (e.g. an “invalid file format” or “invalid ELF target” message would definitely suggest a wrong toolchain being used).

[support]

Hi,

Yes, we have published a detailed tutorial last week: https://visualgdb.com/tutorials/arm/mbed/lpc1549/

[support]

Hi,

Sorry, if you want to import complex 3rd-party projects into VisualGDB, you do need to understand how to build them manually and locate/install the necessary build tools. VisualGDB can simplify a lot of the common tasks through features like automatic header discovery, but it requires understanding of the underlying build process if you want to go beyond creating & modifying basic samples that work out-of-the-box.

Our best advice would be to check with the project vendor for specific steps required to build the project under Windows.

[support]

Hi,

This would normally indicate a problem with the project’s Makefile and selecting a different VisualGDB configuration won’t affect this.

Please try checking if you can build the project on Windows via command line (by running make.exe manually). If not, the project’s build scripts may not be compatible with Windows and would need to be fixed before you can import the project into VisualGDB.

[support]

Hi,

This is actually by design and replicates the regular VS debugging experience. The watch window and hardware registers are only active when the target is stopped (e.g. at a breakpoint). To view the variables while the target is running, please use the Live Variables window.

[support]

Hi,

Thanks for pointing out the incorrect FLASH size. We have double-checked the Olimex board we used and it indeed has 16 megabits of FLASH, although the default 32m setting worked for us. We will investigate this further and update the tutorial. Most likely the FLASH size matters for either the ESP8266 bootloader or some part of the system library that might have been slightly different in your case.

Regarding stepping over and breakpoints, ESP8266 as only one hardware breakpoint, so debugging experience is extremely limited. It is recommended to explicitly move all the functions that you want to debug to RAM so that VisualGDB can use unlimited software breakpoints instead. Otherwise you would need to disable all breakpoints in order to do stepping (which may still not work as the xtensa gdb often gets confused with function prologues and incoming interrupts).

[support]

Hi,

Thanks, we have managed to reproduce this. Unfortunately this is caused by a bug in VS2017 that causes random crashes after programmatically adding files and folders to Visual C++ projects.

We have submitted a bugreport to Microsoft and are also investigating possible workarounds, but the best short-term solution would be to temporarily downgrade to VS2015.

[support]

The “xxxrker.cpp has changed since last build. Doing full analysis..” message is actually misleading here. It is always shown during code completion runs (including QuickInfo).

Feel free to try this build, it reports the reparsing events in a less confusing way: http://sysprogs.com/files/tmp/VisualGDB-5.3.1.1497.msi

[Author]

Posts