Forum Replies Created
-
Posts
-
Hi,
Thanks for reporting this, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.6.1733.msi
Hi,
We might have been able to pinpoint and fix this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.6.1733.msi
Hi,
Please update to the latest VisualGDB 5.3 Preview 6. It includes new API that lets the OpenOCD package report the FLASH programming progress, so the previous preview builds won’t work with the latest OpenOCD package.
Hi,
Good to know it works. If you ever encounter other issues, feel free to start another topic and we will help.
Please try changing MSBuild verbosity via Tools->Options->Projects and Solutions->Build and Run.
If it does not help, please attach a screenshot of the Output window and we will help you diagnose this.
Hi,
The Clang engine is actually unchanged since Preview 3, so if you are experiencing different behavior, most likely it’s caused by the intermittent nature of the bug. What we usually do internally when investigating intermittent issues is try repeating the same operation 10 times and, how many times this leads to a certain outcome and then compare this number between different setups. We understand this is annoying, however as this bug looks to be specific to your codebase, we cannot offer much other help unless we could reproduce it on our side.
We would advise narrowing down the scope:
- Reduce the solution to just 1 source file (e.g. make a backup of the .vxcproj file and manually remove other <ClCompile> statements from it). Don’t forget to delete the CodeDB folder.
- If the problem still persists, this is very good as it’s most likely not caused by race conditions in the multi-threaded parser and could be isolated. In that case please try reprocessing the file by enabling “Generate preprocessor output” in the file properties and then replacing the original .cpp file with the preprocessed file (it will have all the #include<> statements expanded). Can the problem be still reproduced on a preprocessed file?
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?
