[support]

Hi,

If the problem is related to the scripts, it should be much easier to pinpoint (sorry, we don’t have STM32L071 on our side to reproduce this). Simply run OpenOCD with the -d3 flag, get a list of involved scripts (or manually check the ‘find’ statements) and try replacing half of the involved scripts at a time to see if this affects the behavior. This should help locate the script responsible for the problem in just a few iterations.

[support]

Hi,

Sorry, all we can see from the minidump is that the memory gets corrupt to a point when execution jumps to random addresses, hence it is not possible to pinpoint the problem from the dump alone.

In order for us to pinpoint it, we would need to have a project on our side that causes the crash. Another alternative would be to try identifying the exact sequence of steps that leads to the crash so that we could check the differences between v5.2 and v5.3 related to that steps.

E.g. does the crash happen if you don’t use the “Find all references” and “Go to definition” commands? If yes, what would happen if you remove ALL source files except the one that causes the crash from the project and remove the CodeDB folder? Does the crash still happen?

[support]

Sure, we have attached a screenshot.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks for confirming this. As a quick check, could you please try replacing the OpenOCD executable (not the entire package, e.g. scripts) with the older version and confirm that this fixes the problem? If yes, please try adding “-d3” to the OpenOCD arguments to enable verbose debug logging and try comparing the logs for the old and the new executable. They might explain the differences between the behavior of the 2 versions. If you could attach both logs here, we might be able to tell what has changed and find a way to fix it.

[support]

Hi,

Yes, you could specify it in project properties. Another alternative would be to use this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.5.1722.msi

It supports importing STM32CubeMX projects out-of-the-box and will set all the necessary flags automatically as long as you select “Import an existing STM32CubeMX project” from the wizard.

The feature is very new, so it might have a few bugs here and there, so feel free to let let us know if anything doesn’t work and we will fix it.

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

[Author]

Posts