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

[support]

Hi,

No problem. We have released an updated ESP8266 toolchain based on the latest toolchain from Espressif and the SDK v3.4.

You can download it via VisualGDB Package Manager or directly here: https://gnutoolchains.com/esp8266/

[support]

No problem. Please let us know the CentOS version you are using and also the list of files in the /etc/yum.repos.d directory and we will check what is going on.

[support]

Hi,

Thanks for the detailed demonstration. We have updated Live Watch to properly support statically allocated threads and queues. Please try this build: VisualGDB-5.6.1.4098.msi

[support]

Hi,

You can simply synchronize the cross-toolchain’s sysroot with the target via VisualGDB Project Properties -> Build Settings -> Synchronize Sysroot and then use the regular syntax for library names and directories. You can find more information on the following page: https://visualgdb.com/documentation/linkerinputs/

[support]

Hi,

Please refer to the following documentation page for more details on configuring CodeJumps: https://visualgdb.com/documentation/intellisense/#codejumps

[support]

Hi,

There is no special command to deploy the application, however you can script it via the Custom Shortcuts, or simply use the Debug->Start Without Debugging command.

[support]

Hi,

This is something to check on the VS side. VisualGDB reports the sketch files, source files and SPIFFS folder contents in exactly the same way. We have also double-checked it with git integration and it worked as expected as well.

[Author]

Posts