[support]

The setting depends on the version you are using. Please post the contents of the About window so that we could help you.

[support]

Hi,

This doesn’t look like VisualGDB 5.3 Preview 5. Could you please post your “About VisualGDB” window as well?

[support]

The “automatic stack checking” can be disabled via VisualGDB Project Properties -> Advanced Debug -> Validate stack pointer when starting debugging.

However it will not fix the problem. The stack validation fails because VisualGDB fails to start a debug session (because it cannot load the debugger plugin). We understand that this is annoying and will be happy to help if you, however it looks like something on your machine (corrupt registry? antivirus?) is interfering with VisualGDB internals and selectively prevents it from loading some of its components. This could be tough to diagnose as this is not a usual type of error that VisualGDB would expect.

Please send us the screenshot of the empty device selector (and the first page of VisualGDB Project Wizard) so that we could check if any of your selections could be causing this. Please also try alternate means of reaching to the Debug Settings page (e.g. selecting “specify flags manually” in the wizard or opening your project and locating Debug Settings in VisualGDB Project Properties). The Debug Settings page should reveal what is going on.

[support]

Hi,

Normally VisualGDB should not leave anything behind except for the %LOCALAPPDATA%\VisualGDB and %APPDATA%\VisualGDB folders.

Could you try selecting any other device when creating a project (or using the manual mode) so that you could still get to the “Debug Settings” page?

[support]

Hi,

Please try this VisualGDB build: http://sysprogs.com/files/tmp/VisualGDB-5.3.5.1716.msi. It should display a detailed error message on the Debug Settings page if a debug method fails to load properly.

The regular VisualGDB license only includes email/forum support; the only alternative would be our short-term consulting (we do screen sharing & phone sessions to help our customers with a wide variety of problems for $300/hour). We would encourage you to try the build mentioned above first, as it should normally pinpoint any plugin loading issues very transparently.

[support]

Thanks for sharing this, good to know it works.

[support]

Hi,

Most likely your device is using a different clock frequency than the device used in the default USB communication sample. Please try locating a sample for your device/board in the ST samples folder and copying the SystemClock_Config() function from it.

Another alternative would be to select “Use STM32CubeMX samples” when creating a new project. This will locate a matching ST sample for your board that should have the correct clock settings specified.

[support]

Hi,

This could happen if your Makefile contained a target structure that cannot be easily parallelized. Also the MinGW Make has a bug that often hangs it when using multi-core mode. Our best advice would be to try switching the project to MSBuild. It’s not officially supported for MinGW/Cygwin projects, however if you add the ‘VisualGDB’ platform to the project and manually enter the toolchain location via VS project properties, VisualGDB should pick it up. MSBuild does not rely on Make for local builds, so it will work much faster. If it does not work, let us know and we will try to help.

[support]

Hi,

Please try removing the reference to the “STM32 HAL” on the Embedded Frameworks page of VisualGDB Project Properties.

[support]

Hi,

This is actually a common point of confusion, so the next VisualGDB preview will come with support for easy out-of-the-box importing of STM32CubeMX projects.

[support]

Hi,

Thanks for sharing this, good to know that it works.

[support]

Hi,

Are you still using VisualGDB 5.3 Preview 5? If yes, please check that the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\SeggerEDP.dll file exists. If it does, please check the Debug Settings page again. Does it show any settings below the “Segger J-Link” item?

[support]

Hi,

This happens if your PATH variable contains multiple Cygwin directories. ESP32 cygwin binaries would try to load an incompatible version of cygwin1.dll causing this problem.

Please double-check your PATH and remove other Cygwin directories from it.

[support]

Hi,

OK, thanks, the issue was caused by the FLASH initialization code timing out. We have fixed this in an update to our OpenOCD package and also updated the flash_drivers examples to specify the timeout values instead of hardcoding them in OpenOCD.

[support]

Hi,

Thanks, it looks like the debug plugin failed to load. Please try deleting the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp folder, restarting Visual Studio and creating a new project from scratch. VisualGDB should re-download the plugin. If it does not solve the problem, please check that the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\SeggerEDP.dll file is present. If not, please check your antivirus logs, it might be removing the DLL during the installation.

[Author]

Posts