[support]

Hi,

Thanks for renewing your license.

VisualGDB uses the regular Visual Studio color storage to manage its syntax highlighting colors. Sometimes, changing the theme breaks the values stored there, and restarting VS normally restores them. If not, changing the theme there and back, and then restarting typically fully fixes the colors.

If a specific color is off, you can change it directly as shown on this page: https://visualgdb.com/documentation/colors/

[support]

Thanks, this looks like a known issue of the new toolchain. We are not aware of any workarounds yet, so if it is affecting you, please consider downgrading it until we figure out a better solution.

The warning message you mentioned is described here: https://visualgdb.com/documentation/semihosting/#notimpl

[support]

Hi,

The -gdb-version is the first command sent by VisualGDB to GDB. If it times out, it means that the GDB executable takes that long to initialize. You can try running it manually with the same arguments used by VisualGDB and see if there is any pattern.

The delay can also be caused by your antivirus or could be related to the latest ARM toolchain that takes considerably longer to load some symbols. If it only happens for embedded ARM projects and reverting to an older toolchain fixes it, please let us know and we will investigate it more.

[support]

Hi,

Thanks, we have reproduced the issue on our side, although it only took 5 seconds with the latest GDB 12 vs. instant with GDB 10.

Based on a quick look, gdb keeps looking for the .dwp file (separate file with debug symbols) and it appears to trigger some strange bug on the Windows side. The issue also appears intermittent – about 1/3 of runs the symbols load instantly.

You can try disabling Windows Defender – it could be related to the bug. If it doesn’t help, you can replace the gdb binary in the new toolchain with the one from the old toolchain. It will not affect the code produced by the compiler.

We will run some more tests on it next week and will see if there is a better workaround.

As for the not implemented and will always fail error, please see this page: https://visualgdb.com/documentation/semihosting/#notimpl

[support]

Hi,

It could be a bug in the new GDB. We have checked it and it looks like ARM released another minor update.

Could you try using this gdb version [arm-none-eabi-gdb.exe​]? Is it also slow?

Also if you could share the ELF file via our support form, we can try a few workarounds and see if the slowdown could be easily avoided.

[support]

Hi,

No problem. You can easily override the normal EmbeddedBSPs directory via HKCU\SOFTWARE\Sysprogs\VisualGDB\BSPEngine\BaseDirectory. E.g. setting it to C:\BSPs will place the BSPs in C:\BSPs\EmbeddedBSPs.

[support]

Indeed, it looks like a conflict between STM32CubeMX and JRE.

The latest versions of STM32CubeMX come with their own copy of JRE (normally located in <STM32CubeMX directory>\jre\bin\java.exe), so you can simply point VisualGDB to it on the first page of the STM32CubeMX Project Wizard.

[support]

Hi,

The Local System account has a few things different from the regular accounts, so it may break many things you would normally not expect to break (e.g. in MSBuild itself).

You can try installing it by following the steps on this page, but it may still not work as expected, or require non-trivial troubleshooting.

That said, normally you should not need it – the VisualGDB installer integrates it directly into the VS installation, so it should be visible to all user accounts on the same machine (you may need to specify the floating license key via HKCU registry for each of them though).

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[support]

Hi,

Our advice would be the same as to the previous posters: please try building the project outside VisualGDB. If you are not sure how to do that, please let us know the project type (Arduino, ESP-IDF, MSBuild, GNU Make, CMake, etc). and we will point you to the relevant documentation.

If it also takes forever, the issue is not due to VisualGDB and could be caused by the antivirus, defective SSD, or CPU being used by something else. We can suggest a few things to try if this is the case.

If if builds really fast outside VisualGDB, but slow with VisualGDB, it could be due to VisualGDB’s parsing of the long output lines, or due to different antivirus settings or environment. The first thing to check would be whether the build output contains many lines.

[support]

Hi,

Sorry for the delay with updating IntelliSense. In the past year we have been working on a new software tracing engine that allows recording the values of various variables at arbitrary moments without disrupting the program. It allows easily debugging issues that would otherwise be impossible to reproduce under debugger, or that would require excessive amount of stepping and note-taking. So, we prioritized it over the IntelliSense engine update.

We have recently released VisualGDB 6.0 Beta 1 introducing the tracing engine, and are working on another update to it.

IntelliSense update is the next thing on our plan and we expect to release another Beta using the latest Clang in September.

As a workaround until then, please consider adding “-std=c++17” to VisualGDB Project Properties -> IntelliSense Settings -> Additional flags for C++ files. It will allow IntelliSense to recognize C++17 features even if the underlying build system reports that it’s using C++20.

[support]

Hi,

You might be able to get VisualGDB running under the local system account by manually copying the files and registry keys, however it is not officially supported. There is some information here, however it may not work, or may work differently dependent on your configuration.

A better approach would be to use a floating license for the build server. It will count the number of simultaneously active machines instead of concurrent installations, so you can have as many computer/user combinations as you need without needing to activate them separately. Feel free to contact our sales if you would like to switch your license into a floating one.

[support]

Hi,

We are not aware of this issue. It can be caused by a VS bug, interference with another plugin or something else.

Please try checking if the problem persists on a clean project created from scratch. If no, please try to understand the differences between the clean project where the issue happens. It could be triggered by a specific setting.

You can also try recording a video showing the problem on an existing project – if it’s something obvious, we will point it out.

[support]

Hi,

This sounds like a very specific task. You should be able to do it via some clever scripting and custom CMake targets, but it’s not something VisualGDB has a direct GUI for.

[support]

Hi,

The –set-section-alignment argument is used by MSBuild projects to align the embedded bootloader to the specified boundary. You can find the implementation details in the <VisualGDB directory>\MSBuild\Targets\binary.targets file.

If you are using an older toolchain that doesn’t support it, you can either try patching binary.targets to remove the -set-section-alignment part, or simply copy arm-none-eabi-objcopy.exe from a newer toolchain. Objcopy is only used for translating between various file formats (ELF/HEX/binary) and won’t affect the output of the compiler.

[Author]

Posts