Forum Replies Created
-
Posts
-
Hi,
That could do as well. Either way, if you decide to give MSBuild a try, let us know and we will help you set it up.
Hi,
That actually looks like our bug (the feature got disabled on non-Custom licenses). We have re-uploaded the preview 6 build, please update your installation.
Hi,
Are you using VisualGDB 5.3? The previous version (v5.2) had a bug that considered every file with auto-discovered directories out-of-date and it caused very similar behavior.
Hi,
Please try downloading the latest VisualGDB 5.3 Preview 6. It supports importing STM32CubeMX projects automatically as shown in this tutorial: https://visualgdb.com/tutorials/arm/stm32/cube/
We may support out-of-the-box Keil importing in the next VisualGDB version (after 5.3), however we would not promise any timelines yet. Instead we made our project importer framework open-source and published to code for the STM32CubeMX and IAR importers, so any project formats not currently supported could be added easily (VisualGDB takes care of all the heavy lifting with synchronizing the changes and updating project files).
Hi,
It’s actually a bit more complex. If you are not familiar with the STM32 clock settings, please try using the STM32CubeMX tool to specify them graphically (see this tutorial for details). You can also try contacting Olimex for examples that work with their board.
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.
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?
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.
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.
The setting depends on the version you are using. Please post the contents of the About window so that we could help you.
Hi,
This doesn’t look like VisualGDB 5.3 Preview 5. Could you please post your “About VisualGDB” window as well?
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.
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?
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.
