[support]

Hi,

Sorry, we don’t have a ready-to-use visualizer of unordered_map yet. It is on the roadmap, however it’s hard to give any time estimates now. As a workaround, please consider creating one manually as shown in this tutorial.

[support]

Hi,

It looks like you are using a toolchain that outputs dependency files in a format incompatible with Ninja. Please try using our latest ARM toolchain instead and it will work out-of-the-box.

[support]

Hi,

We have rechecked the logic for detecting toolchain settings on the latest GNU ARM toolchain v10.2.1 and it worked as expected. It is hard to say what is causing the behavior your described, however it replacing the file manually works, we would simply advise doing so until we release a fully tested pre-packaged toolchain based on the latest GCC.

[support]

Hi,

You can simply move the directory manually and then import it into VisualGDB by clicking “Install Raspberry Pi Pico SDK” in the SDK selector (in the wizard or VisualGDB Project Properties) and pointing VisualGDB to the new location of the SDK.

[support]

Hi,

We may do it in the future, but since VisualGDB allows importing existing projects very easily, you can simply use the import mode of the wizard to import any examples you prefer.

[support]

Hi,

Yes, please try checking with the Espressif support. The OpenOCD fork is maintained by them, so they might have a better insight into it.

[support]

Hi,

You can simply override the path to the main executable via VisualGDB Project Properties -> Debug Settings so that VisualGDB will launch the .Net runtime with the correct parameters. As long as the library is loaded into the same address space, you should be able to debug it.

[support]

Hi,

Using the custom debug step (before launching debugger) should work. If you believe it doesn’t, please share the screenshots of all the relevant settings and the gdb log showing the commands sent by VisualGDB, and we will look further into this.

[support]

Hi,

Indeed, VisualGDB does not query symlinks each time due to performance constraints. It expects you to configure the path mappings that would work with the paths reported by gdb via VisualGDB Project Properties.

You can recheck the paths via the GDB Session window. Simply locate the path reported by gdb in the gdb log and match it against the list of mappings shown when you click the “Edit Path Mapping” button. The window will show the exact mappings used by VisualGDB, including the ones inherited from the toolchain.

[support]

Hi,

There is no special trick needed. First time you use the toolchain for a project, VisualGDB will run the gcc executable, extract its specs and build an IntelliSense.props file based on them. The file will be used to configure IntelliSense.

If something interferes with this (e.g. GCC fails to run during specs detection), the IntelliSense.props file may end up empty and won’t work.

You can try rebuilding the toolchain-specific files via VisualGDB Project Properties -> MSBuild Settings -> Regenerate MSBuild-specific files. If this doesn’t help, please try checking View->Other Windows->VisualGDB Diagnostics Console during the toolchain testing – it may explain why it fails.

Another workaround would be to copy the IntelliSense.props file from our ARM toolchain.

[support]

Hi,

VisualGDB would stop in the main() function if the user has set one or more breakpoints elsewhere and they have not been resolved at the time of load. This prevents the program from just running through without hitting any breakpoints and gives a chance to investigate it and correct path mapping errors.

Either way, we have added an option (Tools->Options->VisualGDB->General->Debug->Stop if All Breakpoints are Pending) to disable this behavior to the following build: VisualGDB-5.6.1.4102.msi. You can also find a comprehensive list of VisualGDB settings here: https://visualgdb.com/settings/

Regarding the windows, most likely you close the GDB session or the output window at some point, instead of just leaving it in the background. Due to the way VisualGDB handles it, it needs to re-create the window when it becomes relevant, bringing it into focus. Simply keeping it open in the background should work as long as you have the automatic window activation disabled. If not, please try determining a reliable set of steps to reproduce the issue so that we could try reproducing it on our side.

[support]

Hi,

We add direct support for new devices based on their relative popularity and the complexity of the SDK. As the STM32WL devices are very niche, are not relevant to most of our users, and rely on a very complex SDK, we do not have any plans for supporting them directly unless someone agrees to cover the costs of parsing and integrating the STM32WL SDK.

That said, you can always configure VisualGDB to target a device that is not directly supported by following our legacy device tutorial.

[support]

Hi,

Sorry, we do not have any documentation specific to building Raspberry Pi toolchains. Please consider posting on Raspberry Pi forum if you need help building one.

[support]

Hi,

Please try updating to VisualGDB 5.6 Beta 1. If the problem persists, please share the updated exception trace.

[support]

Hi,

VisualGDB itself would not modify the stack pointer unless you change it via the Watch window. However, because stopping the CPU does not always stop other peripherals (e.g. timers, DMA), stepping through code could trigger bugs that would otherwise never happen. You can try creating a GDB log to double-check the communication between VisualGDB and the target.

The watchdog issue is likely similar – stopping the CPU in the debugger likely doesn’t stop the watchdog, and it ends up resetting the chip. One option would be to try selecting OpenOCD (ST fork) as the debug method and then clicking the “Stop Watchdog” checkbox. It will suspend the watchdog while the CPU is stopped in the debugger.

Generally, as the issue is hardware-specific, the support we can provide here is somewhat limited. If you can get it working with another GDB-based IDE (e.g. STM32CubeIDE), we can help you configure VisualGDB to match the results. If the device generally behaves incorrectly when debugged, VisualGDB will not automatically fix it, as it uses the same mechanisms as other debuggers.

If you would like us to review your project structure, debug configuration, and advise a specific debugging setup, we can gladly do it as a part of our consulting services, however we will have to charge a consulting fee for it.

[Author]

Posts