Forum Replies Created
-
Posts
-
Hi,
We are sorry about the inconvenience you are experiencing. We do actually provide a basic reference on the type visualizer-related API: http://visualgdb.com/SDK/reference and the documentation XML files are shipped with VisualGDB, so Visual Studio should automatically display the help for all common methods and types when you are viewing them via IntelliSense.
Either way, we will try to help you pinpoint this by sharing some insight into how the filters work.
VisualGDB uses two-step matching to find expression filters. First it checks if the expression type contains any of the triggers exported by the filters. Trigger matching is a simple case-sensitive substring search. I.e. masks like “Vector<*>” won’t work when entered in the triggers.
The second step of the matching is calling the Probe() method so that the filter can check the expression against an arbitrary set of conditions (e.g. regular expressions). This step is easy to debug by placing a breakpoint inside your Probe() implementation and stepping through it to see why it is not succeeding.
If you experience troubles with getting your filters loaded, the problem could happen in one of the 3 places:
- Your filter is being filtered out due to triggers
- Your filter’s Probe() method does not return a valid value
- Your filter successfully attaches, but does not actually filter the expression correctly
You can easily pinpoint the location of the problem by reducing the triggers to something trivial (or just an empty string to get triggered for every variable) and stepping through the Probe() method. Please also check the outer Visual Studio’s Output log for information on thrown exceptions. If your filter accidentally throws an exception during initialization, VisualGDB would simply skip using the filter.
If this does not help, please let us know what you observe (i.e. which methods of your filter are called and what do you observe in VS) and we will help you sort it out.
Hi,
This could happen if some files were in use. Please try deleting the toolchain manually and then installing it again.
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.
