[support]

Hi,

Thanks for clarifying the constructor initialization list issue and providing detailed screenshots. As the clang-format logic comes directly from the clang codebase, we won’t be able to maintain a parallel formatting engine with an extended set of formatting rules/options. However if you could convince the Clang maintainers to add the advanced options you require to their codebase (e.g. by sending them a merge request), we should be able to update our engine promptly.

The “preprocessor keywords” indeed looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2358.msi

For user types in templates VisualGDB uses a separate setting – C++ Template Type Parameters. Please consider changing it additionally to C++ User Types.

[support]

Hi,

Thanks for checking that SmarTTY works, however this is unfortunately insufficient to track this down. Please try running xterm via SmarTTY and let us know if it shows the window on the Windows side correctly.

[support]

Hi,

Please try clicking the round expander button in the progress window and then check for the build error messages (or use View->Other Windows->VisualKernel Diagnostics Console).

Most likely your kernel is missing some of the configuration options required for the optimized module handling logic.

[support]

Hi,

Sorry about that, looks like one of the caches wasn’t properly updated on our server. Please try updating your BSP again, now it should show 4.7R2.

[support]

Hi,

This looks like an issue that is already fixed in the STM32 BSP v4.7R2. Please ensure you update to this version.

[support]

Hi,

No problem. We have rechecked our profiler framework in the maximum warning mode and took care of the most issues. Please update to the latest 2.17 package.

If you would like to resolve any further advanced warnings, please send us a patch based on the v2.17  package source and we should be able to integrate it into our source tree (as long as it doesn’t break any functionality).

[support]

Hi,

VisualGDB uses a different approach when dealing with CMake projects. Instead of generating a second project from the CMakeLists.txt files, VisualGDB can open the CMake project directly as a regular Visual Studio project. This is fully supported for Linux targets (see this tutorial) and is partially supported for embedded targets (importing existing code is supported, but features like Embedded Frameworks won’t work yet).

We would advise trying VisualGDB 5.4 Preview 3 and importing your project by selecting “Create a project built with command-line tools” -> “Import a CMake project” -> “Use the advanced CMake Project Subsystem”. If this doesn’t work, please let us know more about the errors you encounter and we can help you resolve them.

[support]

Hi,

It looks like Visual Studio might have cached the old toolchain list. Please try restarting it.

[support]

Hi,

Sorry for the confusion. Could you please confirm whether the method disappeared for ESP8266/ESP32 devices or for ARM devices?

The ESP8266/ESP32 devices are not supported by the Segger J-Link GDB Stub, so the only way to use Segger J-Link with them is via OpenOCD (VisualGDB supports it). You can use this mode by selecting OpenOCD as the debug method and then picking J-Link as the interface (or switching to the “USB Devices” view and letting VisualGDB handle the debug method selection automatically).

[support]

Hi,

Thanks for renewing your license. There are a few different ways in which VisualGDB can handle X11-based applications, so please let us know the following:

• Are you building the code on the device, or using a cross-compiler (that involves gdbserver)?
• Are you redirecting X11 windows to the Windows machine, or showing them on the target device (via VisualGDB Project Properties -> Debug Settings)?

Also do the regular X11-based tools (e.g. xterm) work when launched over SSH with SmarTTY or when launched directly using the keyboard/video output on the board?

[support]

Hi,

No problem. Feel free to ping us once your license gets renewed and we can share some tricks on diagnosing this.

[support]

Hi,

Thanks for the update and sorry for the confusion. The original code looked like a Linux application, where the C library is completely outside VisualGDB’s control. For embedded projects there are indeed several versions of the syscall implementations for different scenarios (e.g. with/without semihosting). VisualGDB should also be able to automatically download symbols and sources for those libraries and let you step into the syscalls, helping quickly understand which version is being used.

[support]

Hi,

First of all, please try adding the sources from the root directory of your library via Add->Existing item. VisualGDB will automatically add the correct relative path to the COMPONENT_SRCDIRS statement in component.mk, e.g.:

COMPONENT_SRCDIRS += ../../../../library

Then you can modify it to include all necessary subdirectories, e.g.:

COMPONENT_SRCDIRS += ../../../../library \
../../../../library/subdir1 \
../../../../library/subdir2

[support]

Hi,

Sorry, this doesn’t look like a VisualGDB-related issue, so we are not able to provide much help with this. The best advice we could give would be to look through the source code of your C library or asking on StackOverflow.

[support]

Hi,

According to our records, your technical support period has expired. In order to keep on receiving technical support, please renew your license.

[Author]

Posts