[support]

Hi,

OK, we have reviewed our tutorials and indeed found a few confusing things. The most confusing part is that the older tutorials are showing the GNU Make build system and don’t show many features introduced later. We created a list of the most outdated tutorials and started updating them. So far, we have updated these tutorials:

• Developing firmware for EFM32 devices – showed the Advanced CMake workflow and the new Live Watch GUI.
• Using Visual Studio to develop Linux Apps – showed MSBuild instead of GNU Make and explained the differences between MSBuild and CMake.
• Developing a Raspberry Pi app with Visual Studio – showed MSBuild instead of GNU Make and the new Code Jumps GUI.
• Adding External Memories to Embedded projects – showed the new OpenOCD configuration GUI and the new Memory Explorer.
• Developing OpenOCD FLASH drivers for External Memories – showed the improved CMake workflow (instead of GNU Make) and the use of Software Tracing to record the issued QSPI commands.
• Using WiringPi library with Raspberry PI cross-compiler – showed MSBuild instead of GNU Make and gave examples on using automatic header file discovery and library discovery.

We will be updating more tutorials to show features like the new Software Tracing, and will also remove references to GNU Make that has been superseded by CMake.

As for VS Code, it follows somewhat different design principles. Instead of providing GUI for many repetitive tasks, it forces you to change many things manually by editing JSON files. On one hand, it is less productive because it involves more repetitive work. On the other hand, that extra work makes it harder to accidentally change the wrong setting.

VisualGDB is built around a different philosophy – it provides powerful tools for common tasks, but needs more attention when using them. A fairly characteristic example would be the Header Discovery that we showed in the updated wiringPi tutorial. Instead of manually finding the header file, manually computing the relative path, and manually finding and patching the correct CMakeLists.txt file, you can let VisualGDB find all these things for you, review them and commit everything with a few clicks. But if you end up referencing a wrong directory (e.g. for a different target) and then attempt fixing it by referencing several other wrong directories, it would break the project to the point where it’s impossible to tell what’s going on anymore.

We could theoretically try to reduce damage from changing incorrect settings on our side by maintaining a history of what was changed and having an undo button for settings, but it is harder that it seems. Some options (like the configurations/platforms mentioned earlier here) are controlled by the VS directly and hare hard to monitor on our side. Also, the majority of unrecoverable projects are caused by changing something very unexpected and unique (e.g. overwriting a toolchain definition while attempting to fix another issue for another project). The good news is that you can avoid most of such quirks by using source control (or at least, frequent backups) and taking notes when you change something globally (like overwriting global files).

Either way, if you decide to give VisualGDB another try, feel free to get back to us. We can extend your license by the amount of months you skipped. We still can’t promise to fix broken projects without having the repro steps, but we will assign a higher priority to updating the old tutorials and will make sure they match the current GUI.

[support]

Hi,

Thanks for the stack trace. The crash actually happens inside the Visual Studio’s own language service assembly that implements helper functions for IntelliSense back-ends. It is hard to say what exactly triggers it, but AccessViolationException typically indicates corrupt DLLs somewhere.

Doing a fresh complete reinstall of VS should normally fix it.

 

[support]

Hi,

This is a tricky one.  In our experience, the Visual Studio color storage is prone to sometimes resetting/mixing up colors. Normally, VisualGDB can automatically detect it and reset the cache, but it could be that the One Dark Pro uses some other workaround that interferes with it.

Our best advice would be to try the regular VS dark color theme, and tweaking it to match the colors from One Dark Pro.

[support]

Hi,

Thanks for pointing this out. The new Gecko SDK indeed provided its own implementation of _sbrk() that was not fully compatible with the VisualGDB-generated linker scripts.

Since VisualGDB provides its own implementation, it is not really needed. We have updated the BSP removing it. Feel free to re-download it via Tools->VisualGDB->Manage VisualGDB Packages.

[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.

[Author]

Posts