[support]

Hi,

This means that the gdb executable exited before outputting anything at all. Most likely, it is missing some dependencies.

You can try locating it, running it, and manually resolving any missing dependencies it reports. You can also try replacing it with the gdb binary from our ARM toolchain.

[support]

Hi,

The screenshot you attached shows the generic message, but does not show the actual gdb log. You can view the log by clicking on the “GDB session” tab in the error window.

[support]

Hi,

There are 2 ways of programming the FLASH memory for Arduino projects:

• The context menu command in Solution Explorer will use the Arduino-level commands to do it. This is what the log shows.
• Debug->Program and Start Without Debugging will use the VisualGDB-level logic. Specifically, it will start a debug session, program the FLASH memory, and immediately detach from the target.

[support]

Hi,

No problem. Our previous EFM32 package was based on an older Gecko SDK (4.0.2). We have just updated it based on the latest release from Github (4.2.4, 32-bit SDK version 6.4.4).

If you would like to use the SDK files that are not included in the BSP, you can manually clone the SDK (make sure you are using the same version) and add the files to the project. If you would like to pull some of the libraries from the SDK into the BSP so that they could be added via VisualGDB GUI, you can patch our EFM32 BSP Generator. It currently only wraps the most basic libraries.

We also updated our EFM32 tutorial showing the new VisualGDB GUI and explaining how to find the SDK version.

[support]

No problem, we will try to explain our approach here.

The original poster did not mention adding a new configuration via VS Configuration Manager. They mentioned adding a source file via Solution Explorer, that does not lead to this error. So they must have done something else at the same time. They could have added a configuration just like you did, or they could have:

• Accidentally deleted the .vgdbsettings file (antivirus does this sometimes)
• Copied and renamed the project from a different location, but not updated the .vgdbsettings file
• Manually converted a non-VisualGDB configuration to a VisualGDB-based one
• Accidentally changed the .vgdbsettings file name in the configuration, intending to change it in another configuration
• Manually edited the .vcxproj file, trying to achieve something else

All these examples were taken from actual tickets submitted by other users. There are many other things that could have triggered the same error. In our experience, unless the user mentions exactly what they did, it’s practically impossible for us to guess it.

We initially tried suggesting the most common causes when users reported unreproduceable issues like this. It didn’t work out – the error was always somewhere else, the users would not have the patience to try every step we suggested, so they would submit more and more problems that we were powerless to solve. They were convinced that our product is buggy, getting increasingly more frustrated with every ticket; and we couldn’t do anything to help them because the steps they provided always worked just fine on our side, and the problem was triggered by steps they didn’t mention.

So we changed our approach – whenever someone reports an issue that we cannot reproduce, we ask to provide clear repro steps from scratch. As long as we can see what is going on, we can usually give meaningful advice. E.g. you mentioned using the VS configuration manager – indeed it will not update the VisualGDB files correctly. Instead you can use the Manage Configurations button in the top right corner of the VisualGDB Project Properties window – it will take care of both VS-level and VisualGDB-level settings automatically. But we really, really need to see what the user is actually doing to trigger the problem. Without it, the chance of suggesting anything remotely relevant is close to zero.

 

[support]

Hi

No problem, we will try to help you. First of all, please try updating to VisualGDB 6.0 Beta 1. If the problem persists, please try obtaining a stack trace of the crash as shown here: https://visualgdb.com/support/callstack

[support]

Hi,

It is probably caused by some rare combination of settings you use on both computers, or by a conflict with another VS extension. Our best advice would be to first try disabling other VS extensions. If it doesnt’ solve the problem, try pinpointing one specific color that gets broken (e.g. the preprocessor directives shown on the screenshots) and try manually overriding it to something visually different (e.g. green), and restarting VS a few times. Does the setting get reverted at any point? If yes, is there a specific trigger to it?

[support]

Hi,

We used the source from here and the default configuration line:

../gdb-13.2/configure --target=arm-none-eabi --host=i686-w64-mingw32

No idea why the binaries shipped by ARM work differently.

[support]

Update: We have run some additional tests and it looks like the problem only happens with the gdb binaries shipped with the original ARM toolchain. We built the latest gdb 13.2 from sources, and it manages to load the symbols instantly, just like the older gdb versions.

We have published an updated ARM toolchain that replaces the GDB binary with the one we built. You can install it via VisualGDB Package Manager or directly from here: arm-eabi-gcc12.3.1.exe

[support]

Hi,

We have run some additional tests and it looks like the problem only happens with the gdb binaries shipped with the original ARM toolchain. We built the latest gdb 13.2 from sources, and it manages to load the symbols instantly, just like the older gdb versions.

We have published an updated ARM toolchain that replaces the GDB binary with the one we built. You can install it via VisualGDB Package Manager or directly from here: arm-eabi-gcc12.3.1.exe

[support]

Hi,

It looks like the toolchain you are using, or the project itself, is broken. VisualGDB cannot automatically fix – all it can do is provide convenient configuration and debugging GUI that can make the development easier.

Please make sure you can build the project for the same device using the same toolchain and build system outside VisualGDB first. Once it works, feel free to share more details about your setup and we will help you configure VisualGDB to build and debug the project.

[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

[Author]

Posts