Forum Replies Created
-
Posts
-
Hi,
No problem, we can gladly look into this. Do you mind sharing a screenshot of the entire Visual Studio window demonstrating the issue? The screenshot should also show the Solution Explorer and at least one source file (it’s important for checking for common module loading issues).
Hi,
No problem. VisualGDB comes with out-of-the-box support for FreeRTOS, RTX and Zephyr (NRFConnect SDK only). If you would like to target an RTOS that is not currently supported, you would need to fork our FreeRTOS plugin, and update it to handle the RTOS you are using.
As uC/OS III has a much smaller user base compared to FreeRTOS, we are not planning to support it out-of-the-box, unless some of our customers agrees to directly cover the associated porting costs.
Hi,
Indeed, the Clang-based IntelliSense engine used by VisualGDB does not rely on the .editorconfig files. It instead uses either the registry settings (when using the legacy formatter) or the .clang-format files when using clang-format.
Please refer to the following page for detailed documentation: https://visualgdb.com/documentation/intellisense/#formatting
Hi,
Please refer to the emails from our support on 2021-10-02 and 2021-10-03 for a detailed explanation on what to expect from VisualGDB. We handle support inquiries and forum inquiries exactly the same way, so the same rules apply in both cases.
Please also feel free to refer to our project importing documentation for a very detailed explanation. In short, if you would like the import to work 100% automatically, being able to build the project via command line is a requirement.
From the VisualGDB side, there is no difference between these cases. If you can build the project via command line outside VisualGDB, you can import it into VisualGDB as shown in the tutorial. If you cannot build it outside VisualGDB either, simply importing it into VisualGDB will not automatically fix the build issues.
Hi,
Sorry about the confusion. Please consider updating to VisualGDB 5.6 Beta 5. It supports installing the .vgdbpkg files directly from the Package Manager.
Hi,
No problem, we have updated our package list page to show auxiliary packages, such as CMake. You can install the downloaded package files via Tools->VisualGDB->Manage VisualGDB Packages.
Hi,
You can import existing projects into VisualGDB using the “import” mode in the wizard as shown here: https://visualgdb.com/tutorials/arm/import/
This could be related to a VS MEF cache bug. Please try restarting Visual Studio. If it doesn’t help, please try right-clicking on the tab header of the source file that is not loading, and select “copy full path”. Please share the full path here, and we will help you get it working.
We usually answer most inquiries within 1-2 business days. There is no need to create multiple tickets for the same issue, as they go through the same queue anyway.
Please note that the exact logic for recompilation it managed by ESP-IDF and not by VisualGDB. As far as our support goes, we can help if VisualGDB working on top of ESP-IDF produces different results from using ESP-IDF directly. For all issues that are also present in the ESP-IDF itself, please contact Espressif.
Regarding the max. items per CMakeLists line, VisualGDB picks it up automatically. For each statement, it detects and preserves:
- The indentation of the 1st line
- The indentation of other lines
- The number of items on the 1st line
- The max. number of items on other lines
Hence, there is no need to change any settings. Simply format the statement the way you prefer, and VisualGDB will preserve it when updating the statement.
Thanks for the detailed description. This looks like an issue with the environment variable expansion that was fixed in VisualGDB 5.6.
The stack trace looks like VisualGDB is trying to read the contents of one of the source files on the remote machine. It could freeze VS if the project contained files called aux.c or com[1-4].c, although VisualGDB 5.6 contains a check for this. Either way, please try updating to the latest Beta (or VisualGDB-5.6.5.4391.msi) and let us know if the problem persists.
Hi,
No problem. If Visual Studio locks up, please try obtaining a stack trace as shown here. If it contains VisualGDB frames, please attach it here along with your VisualGDB build number, and we will investigate further.
The second issue looks like your gdb executable crashes. Please first make sure you can debug your program manually by running gdb manually on the same machine and with the same gdb you are intending to use with VisualGDB. If you can do that without crashing, we can gladly help you configure VisualGDB to replicate the same setup.
If the toolchain appears broken and doesn’t work, we can also gladly investigate it your you and build a custom toolchain that will work with your target. Feel free to reach out to our sales if you would like to get a quote on that.
Hi,
No problem. Please refer to our MSBuild documentation page for a detailed description of different files used by VisualGDB projects.
