Forum Replies Created
-
Posts
-
Hi,
You can install both toolchains side-by-side, as long as you use the “online” view in the VisualGDB Package Manager and manually specify a different directory (or just download and run the installer manually). The “update” view is intended for replacing the older toolchains, and will indeed overwrite it.
For convenience, you can always select to ignore a specific update, so VisualGDB won’t suggest it anymore.
Regarding the IDF versions, it sounds like you had experimented with manually installing extra ESP-IDF checkouts into your toolchain, and they got removed when VisualGDB uninstalled the old toolchain during the update process. This is to be expected, as mixing the parts from the old and new toolchain could result in very weird bugs.
In general, if you are playing around with multiple ESP32 toolchain and IDF checkouts, we urge you to keep good notes of the toolchain and IDF versions that work together and double-checking them when you clone the IDF releases manually. Accidentally combining unsupported versions often leads to strange errors.
If you would like to load it manually, just copying the .ko file and running modprobe/insmod should suffice (as long as it’s exactly the same kernel, you don’t need to rebuild it).
You can also copy the sources + Makefile and run make (note that the make command line would need to reference the kernel module script directory, e.g. see this page). Making the module load automatically depends on your Linux version and is usually described in your distro’s documentation. VisualKernel does not configure it automatically.
We have tested it with ARM-USB-OCD-H (see this page), but not with ARM-USB-TINY-H. Olimex probes are based on the same FTDI chip family, so it should work in theory, but we haven’t specifically checked it.
Hi,
No problem, we have released an updated toolchain based on the esp32-2021r5-patch tools with ESP-IDF 4.4.3. You can download it here: https://gnutoolchains.com/esp32/
Please make sure you use the latest VisualGDB build (VisualGDB-5.6.109.4769.msi) that supports the new Python environment layout.
Hi,
This error means that the project file is corrupt and may not work anymore. This type of errors is almost always caused by trying to do multiple new things at once and inadvertently selecting incompatible settings at some point (often while trying to troubleshoot an earlier error).
This is a very common mistake that can be easily avoided by trying new things one at a time and keeping notes of the settings you change, so you can always track them back. Please see this page for a very detailed description and our suggestions on best practices.
Our tutorials follow this approach as well – they demonstrate each individual feature (e.g. using libraries, using header discovery) separately from others, rather than trying to show them all at once and further confusing new users. We recommend using the search bar on the tutorials page to find relevant tutorials and following them as close as possible to get familiar with the related settings.
Please note that we do not update tutorials when introducing minor changes to GUI. If the GUI shown in the tutorial looks slightly different from the latest version, using the settings shown in the tutorial should still work, as long as you try to follow them as close as possible to the tutorial.
Good to know it works. If you encounter further issues with Clang IntelliSense not loading for a particular project, feel free to check this page for detailed troubleshooting instructions.
Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
- The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.
You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.
You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.
Thanks, we have tested the new toolchain together with the ESP-IDF 5.0 and confirm that the basic projects work for the ESP32, ESP32C3, ESP32C3, ESP32S2, ESP32C3 and ESP32H2 devices. We have also retested semihosting (regular ESP32 device only) and adjusted our unit test integration to be compatible with the latest ESP-IDF.
You can download the updated toolchain installer here: https://gnutoolchains.com/esp32/
Please note that ESP-IDF 5.0 uses its own system to manage virtual Python environments, so you would need the following VisualGDB build to use it automatically: VisualGDB-5.6.109.4769.msi
We will run a few further tests and will release an official VisualGDB 5.6R9 with full ESP-IDF 5.0 support in the next few days.
Hi,
This looks like something is off with your PowerShell assembly search path. If you are not comfortable troubleshooting it, we would suggest creating a simple command-line tool using the .Net Framework, referencing all the required assemblies from it, and using the CoverageReportReader class from the tool.
Hi,
Most likely, your project uses custom non-trivial logic for placing the library symbols, and VisualGDB cannot automatically detect where the symbols are.
In order to resolve it, please first go through this tutorial and make sure you understand how to check whether an ELF file contains debug symbols. Then, please inspect your project and find out the exact location of the .so file you are trying to debug. Make sure it contains debugging symbols as per the tutorial. Double-check that the symbols mention the file you are trying to debug. If not, you would need to adjust the build settings to make sure the symbols are not stripped.
Once you confirm that the .so file contains symbols, please inspect the gdb log for the -gdb-set solib-search-path command. VisualGDB uses it to point gdb to the directories with the symbol files that are derived from the CMake code model. If it doesn’t contain the expected directory, you can override it by adding your own set solib-search-path command via VisualGDB Project Properties -> Additional GDB Commands.
In general, VisualGDB computes the solib-search-path from the directories of the target’s references. If it’s missing a particular library, explicitly referencing it from the executable should solve it. You can double-check the references reported by CMake, as well as the exact library locations in the target-XXX.json files inside the build\<subdir>\.cmake directory.
Hi,
Indeed, the VisualGDB CMake projects use a different template mechanism, so it allows adding targets or individual source files, but not whole classes. As a workaround, please consider adding a pair of .cpp and .h files and declaring a class there manually. You can then rely on VisualGDB’s IntelliSense to generate most redundant code for you:
- Once you type in the constructor declaration (e.g. ‘MyClass();’), press Ctrl+. and select “Create a definition”. It will insert the “MyClass::MyClass() {}” part in the .cpp file
- Whenever you want to add a new method to the class, you can try just calling it from the code as if it was there, and then use the “Create from use” command, that will determine the names and types of the arguments based on the values you passed.
Regarding the Visual Studio versions, VisualGDB replaces a lot of the Visual Studio GUI and functionality with its own implementations, and the parts that are not replaced (tab docking, breakpoint/watch GUI), have not changed much between VS2017 and VS2022. On the other hand, VS2019 and VS2022 feature a lot of improvements for the C# development, so if you are occasionally developing C# code, it could be worthwhile checking them out.
Hi,
This means that the project file is corrupt. Please try re-creating the project, or manually checking the location shown in the error message for obvious XML errors.
This error means that Visual Studio refused to save the solution file when VisualGDB requested it. Most likely, it is caused by some setting you picked when creating the project.
Please try starting again and following the tutorial as close as possible. If it doesn’t work, please share the complete steps to reproduce the problem including all the screenshots, and we will try to point out the cause of this issue.
Sure, you can use the CMake Platform Manager to have an arbitrary combination of platforms and configurations.
Every platform/configuration can use a different toolchain, exclude some targets, or tweak how they are built.
