Forum Replies Created
-
Posts
-
Thanks for clarifying this. Please try the latest VisualGDB 5.5 Preview 2. Each time you open a solution containing VisualGDB projects, it will automatically find missing toolchains, BSPs and other items and will show a list of them, allowing you to download or substitute them. You can then use the substitution GUI to find and import the custom toolchain (that should already contain the CustomToolchain.xml file). As long as the ID is the same as the project file references, the .vgdbcmake file won’t need to be updated.
The FindToolchain.props file is not used by Advanced CMake projects. It is only required by VC++-based projects (e.g. MSBuild, GNU Make, etc) and is regenerated automatically based on the known toolchains and other packages each time you start Visual Studio (or specifically, start using VisualGDB functionality inside a newly launched VS instance).
Also, if Team Settings looks like a good fit for you, we can easily update it to allow packaging custom toolchains and automatically installing them on all relevant machines.
Hi,
Thanks for the suggestion. Indeed, importing the toolchains via the Package Manager window is geared towards embedded toolchains. As a workaround, please consider one of the following options:
- Try importing the toolchain from the toolchain selector (i.e. anywhere where you would normally change the toolchain, such as the the project wizard or VisualGDB Project Properties). This will automatically use the toolchain type based on the project type and will allow editing various toolchain parameters.
- You can also simply edit the Toolchain.xml file after the toolchain was imported. The toolchain type and ID are stored in separate XML elements that should be very easy to modify. If you later try to import a toolchain that already has a Toolchain.xml file (or CustomToolchain.xml), VisualGDB will ask whether you want to reuse the existing toolchain definition instead of regenerating it.
Unfortunately, as you have created a high amount of highly specific inquiries (45 topics with 88 posts altogether), we are not able to provide a detailed reply. The documentation about VisualGDB’s and Visual Assist features is available online.
We have to prioritize our support based on the amount of affected users and are not able to provide any further details in this case.
The new build should report missing platforms as well, however only if they are known to VisualGDB (i.e. listed in one of the platform_index.json files configured via Tools->VisualGDB->Arduino->Package index URLs).
Please try clicking “Yes” in the message asking to repair the environment variable and restart your computer. If nothing helps, please make sure you follow all steps from the troubleshooting guide and if this doesn’t help either, please let us know exactly what happens on each step (which files are present, what you have deleted/modified) and we will help you resolve it.
Hi,
Please try following this tutorial for diagnosing library-related problems. For CMake projects, you can find the library-related settings under VS project properties for specific targets (e.g. for your main executable).
Most likely, you have edited some files or configuration entries in the Arduino IDE to resolve this and did not change the VisualGDB configuration accordingly.
Unfortunately, without being able to reproduce the issue on our side (successful build with Arduino IDE and failing build with VisualGDB) it is not possible for us to offer any solution.
Our best advice would be to follow the Arduino Diagnostics Tutorial to compare the command lines used by the Arduino IDE and VisualGDB in order to narrow down the configuration difference.
Sorry, this is way too specific and won’t be of much use for most of our users. In order to keep our product prices reasonable, we focus on features that would appeal to many of our users at the same time. Hence we are not able to add functionality that has very limited use, as we have a backlog of features that would bring productivity improvements to a much larger group of users. Hope this explains and sorry we could not help.
Hi,
Most likely, you are not using the VisualGDB build engine to build the project. Just building the code with the –coverage flag will introduce immense memory overhead, so VisualGDB does some advanced pre-link patching to move most of the coverage logic to the PC side. Please try creating an MSBuild-based projects and check with it instead.
Alternatively, please try running the following command line after compiling the code, but before linking it:
VisualGDB.exe /decover <full path to the ELF file> <full paths to all .o files>
Then re-link your ELF file as usual. This will greatly reduce the memory overhead caused by the code coverage.
We are also preparing a tutorial showing the related settings and best practices. Feel free to follow us on Twitter to get notified once we publish it (or simply check our tutorials list next week).
Hi,
This is already supported via ESP-IDF components. Please refer to the ESP-IDF documentation or VisualGDB tutorials for details on managing the ESP-IDF components.
Sorry about that. We have just caught this with our pre-release tests as well. Please try this build: VisualGDB-5.5.2.3410.msi
We have tried building the configuration you mentioned using Arduino IDE on a clean machine (Arduino IDE 1.8.10, Arduino Core for STM32 v1.7.0, stm32sleep cloned from Github, Generic STM32F1 Board) and it failed with the same error that you reported for VisualGDB:
fatal error: libmaple/gpio.h: No such file or directory
Hence it looks like the problem is caused by a specific 3rd-party library and not by VisualGDB.
Hi,
It looks like your technical support has expired. In order to continue receiving technical support, please renew your support here: https://sysprogs.com/splm/mykey
