[support]

Hi,

VisualGDB would normally remember the USB serial number of the ST-Link you selected in the wizard/project properties and automatically select it next time. It will only show the selection dialog if more than 1 ST-Link is found and none of the found instances has a matching serial number.

If you want to select a specific ST-Link instance, simply pick it on the Debug Settings page of VisualGDB Project Properties (or manually change the serial number stored in the .vgdbsettings file to an invalid value to trigger the selection dialog).

[support]

Hi,

Sorry, not yet. We have done preliminary research and will include this in v5.4, but it isn’t available in Preview 1 yet (and likely won’t be included in Preview 2 that will be focused on J-Trace support).

[support]

Hi,

VisualGDB offers a much more streamlined experience than the regular VS2017 Linux integration. First of all, it uses a highly optimized build backend that works much faster for large projects with complex structure, and is generally more reliable.

Second of all, VisualGDB provides known workarounds for common issues on the underlying Linux tools. Inaccurate path mappings, missing LD_LIBRARY_PATH entries, mismatching interactive/non-interactive environments and many other scenarios. VisualGDB can automatically discover and fix many issues that would normally take hours to diagnose.

Our debug engine is also designed to recover from known gdb bugs and provides deep diagnostic tools (e.g. a tool for analyzing timings of specific underlying commands that help reduce latency on slow connections).

On top of that VisualGDB offers a Clang-based IntelliSense engine that is specifically designed to handle Linux-specific code and provides many C#-like features: detailed code map, create-from-use, etc.

VisualGDB also includes very deep integration with Make, CMake and Qmake that let you use convenient GUI to quickly edit various project settings without the need to understand the specifics of the project file formats. Our Advanced CMake project subsystem brings this even further – it lets you use the regular Solution Explorer GUI to view and edit CMake targets, automatically editing CMakeLists.txt files in response.

Beyond the regular editing and debugging functionality, VisualGDB includes advanced valgrind-based profiler optimized for huge projects, support for running unit tests on Linux machines (with code coverage), static and dynamic code analysis tools and a convenient set of custom actions that lets you easily transfer files between machines as a part of build or while preparing for debugging.

There are also numerous customization options (like using a custom command for sending the ‘break in’ signal to your app if your Linux distro is configured to ignore the regular SIGINT mechanism) that come in handy when dealing with highly customized target environments and features like Team Settings that help you share common settings to other team members instead of painstakingly setting them up on each machine manually.

You can get a quick overview of the Linux-related highlights here or browse through our Linux tutorials here.

Hope this explains. If you have any further questions, feel free to share them and we will be happy to answer them.

[support]

Hi,

Yes, we indeed ship the pre-built recent versions of the GNU tools like GCC and GDB, however unfortunately resolving the internal bugs of those tools is beyond what we can offer. Hence our best advice for this type of problems (if you run into it again and cannot resolve it via compiler settings) would be to downgrade to a previous gdb release until we release another pre-built version based on newer sources.

You can always download the older toolchain versions here: http://gnutoolchains.com/arm-eabi/

Simply copy the arm-eabi-gdb.exe executable from an older toolchain to the newer one and you will be able to use the newest toolchain (including all optimization features it offers) with the old gdb debugger.

 

[support]

Hi,

Thanks for sharing the log. This looks like an internal bug of the gdb debugger included in your toolchain. Please try using a different gdb version (e.g. from an older toolchain), or try changing the debug information format in your project properties as this might stop the bug from being triggered.

[support]

Hi,

Strange, the log doesn’t indicate any known error. As a quick check, does restarting your computer solve the problem?

[support]

Hi,

Thanks, we have reproduced it and fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2127.msi

 

[support]

Hi,

Good to know it works. With linker script, VisualGDB supports 2 levels of specifying it:

• On the Project Properties page. This affects all configurations.
• On the MSBuild Settings page. This overrides the default per-project setting and affects each configuration independently.

If you would like to have different settings for different configurations, please explicitly override the linker script on the MSBuild settings page for each configuration.

[support]

Hi,

Looks like your project is missing a system initialization file. Normally STM32CubeMX should generate it (system_<MCU name>.c), so please double-check your project for this file (or simply search all .c files for SystemInit). You can also reference the “Default System Initialization file” framework via VisualGDB Project Properties, however it might not 100% match your board configuration.

[support]

Hi,

Good to know it works now. If you could let us know what were you selecting before (VisualGDB should normally gray out the ‘next’ button if no toolchain is selected), we should be able to add better handling for this (it might be also already fixed in the recently released v5.4 Preview 1).

[support]

Hi,

Perhaps you have accidentally disabled X11 forwarding? Please double-check that the Program output setting (bottom of the Debug Settings page of VisualGDB Project Properties). Does it state “Forward program output to Visual Studio”? If yes, please also check that X11 forwarding is not disabled via Tools->VisualGDB->SSH Host Manager->Per-host Settings.

[support]

Hi,

No problem. Based on your description, this is most likely caused by some setting specific to your project files.

First of all, please try the recently released VisualGDB 5.4 Preview1: https://sysprogs.com/files/visualgdb/VisualGDB-5.4-preview1.msi

If the problem still persists, please try either attaching one of your project files (.vcxproj, .filters, .vgdbsettings, .props files should be sufficient, you don’t need to attach the actual source code) or attach another VS instance to the primary one (in the Managed Debug mode) and try reproducing the problem. The outer VS instance should catch the crash and display detailed information about it.

[support]

Hi,

Yes, normally just running ESPImageTool.exe <ELF file> [optional FLASH settings] should do the job.

Please feel free to look through this tutorial to get a basic understanding of ESP8266 OTA with VisualGDB: https://visualgdb.com/tutorials/esp8266/ota/

[support]

Hi,

This looks like a limitation of newlib-nano. Please follow the link below for known workarounds: https://github.com/RIOT-OS/RIOT/issues/1891

 

[support]

Hi,

OK, we have released v5.4 Preview 1 that supports the new advanced ESP-IDF project subsystem. You can download the build here. You can read the announcement with the main highlights of the new subsystem here: https://sysprogs.com/w/announcing-visualgdb-5-4-preview-1/.

• This reply was modified 7 years, 6 months ago by support. Reason: release info

[Author]

Posts