Forum Replies Created
-
Posts
-
Thanks for confirming it. Just to double-check, please share a screenshot of the menu command you are using to open VisualGDB Project Properties (the screenshot should include the entire VS window as it may contain important clues).
Please also check View->Other Windows->VisualGDB Diagnostics Console (you would need to enable diagnostic logging before trying to open project properties). It might contain important clues about the error.
Sorry, it looks like your technical support has expired. We could help you resolve the issues you encountered, however we would kindly ask you to renew the support first.
Alternatively, please refer to the following pages for generic instructions on getting old versions:
Hi,
Please try updating to VisualGDB 5.5 Preview 4. It will automatically check for missing packages when loading the project and will suggest automatically downloading/installing them.
Good to know it works. BTW, we have a detailed tutorial showing the necessary steps here: https://visualgdb.com/tutorials/linux/cmake/target_link_libraries/
Please also feel free to try VisualGDB 5.5 Preview 4. It can automatically troubleshoot the “undefined reference” errors and suggest the necessary configuration changes.
No problem, we will explain what is going on.
The VS property sheets have similar semantics to the #include and #define directives of the C/C++ compiler:
- The <Import> tag in a .vcxproj file (or in a .props file) is a rough equivalent of the #include directive.
- The <PropertyGroup> tag is a rough equivalent of a group of #define-s
- The Condition attribute on <PropertyGroup>, or a specific property, is equivalent to wrapping the #define-s with #ifdef/#endif
In order to understand why some properties get overridden, please locate all locations where they are defined (including the VisualGDB’s MSBuild directory and toolchain.props) and reconstruct their order by tracking the <Import> tags. E.g. if the project first imports a property sheet, and then defines the same property in a property group, the project’s property group will override the value from the property sheet. If the property sheet is imported after the definition in the .vcxproj file, it will override the regular definition.
You can also work around this by using the following syntax in the property sheet file:
<PropertyGroup> <MyProperty Condition="'$(MyProperty)' == ''">NewValue</MyProperty> </PropertyGroup>This will only set MyProperty to NewValue if it was unset at the time when the corresponding PropertyGroup was parsed.
The default values shown in the VS GUI are taken from the Microsoft.Cpp.Default.props file that in turn includes the SysprogsPlatform.default.props. If you would like to modify them, consider importing your own property sheet right after (or before) Microsoft.Cpp.Default.props.
Hi,
Most likely, some MSBuild-specific files are corrupt. Please try checking the following:
- Do VisualGDB Project Properties work for a newly created project? If yes, please try comparing it against the broken one.
- Regardless of #1, try holding Shift while right-clicking on the project. This will force the VisualGDB Project Properties command to appear even if VisualGDB does not recognize the project.
- Also try opening the regular VS properties for the project or try building it. This might show a more informative error message.
Thanks, it indeed looks like something coming from the gdbserver (gdb/gdbserver/server.c):
fprintf (stderr, "Detaching from process %d\n", pid);
If you are not comfortable patching/rebuilding it, simply ignoring the message should be the best way.
Our best advice would be to try the Olimex ARM-USB-OCD-H JTAG debugger that is shown in the tutorial and make sure the wiring exactly matches what is shown in the tutorial.
Most likely, you ended up with an incompatible toolchain/ESP-IDF combination. Please see this page for a detailed explanation.
Those settings are defined inside the <PropertyGroup> statements and can also be copied into the property sheet files. Simply copy the <PropertyGroup> statement from the .vcxproj file (removing the Condition attribute) into the property sheet file, and the properties will get applied as if they were defined in the .vcxproj file.
Hi,
It looks like your technical support has expired. Please renew it here and we will help you understand how VisualGDB structures the STM32 projects and how to troubleshoot this type of issues.
No problem, we can help you set it up then. Most likely, you are using different ESP-IDF/toolchain combinations with and without VisualGDB, leading to different results.
In that case, we would advise importing the working toolchain into VisualGDB as described in this post.
If it doesn’t help, please try importing an otherwise working project into VisualGDB using the same toolchain/ESP-IDF and describe what exactly happens when you try to build it manually vs. with VisualGDB. We will then help you replicate the manual build results with VisualGDB.
Regarding supported versions, visualGDB supports ESP-IDF versions up to 4.0 (the latest official release). You can download ready-to-use toolchains together with the compatible ESP-IDF checkouts from our ESP32 toolchain download page. We will support v4.1 once it is officially listed as a stable release on the ESP-IDF releases page.
Hi,
This looks like something coming from the gdb/gdbserver and not directly from VisualGDB, so our best advice would be to search the gdb sources for the “Detaching from process” string, find the line responsible for outputting this message, and check if there is an option that suppresses it. If not, consider patching gdb/gdbserver to remove this line and rebuilding it.
If you cannot find this line in the gdb codebase either, please try creating a minimal repro example and share all relevant screenshots and steps, and we will try to suggest what else could be outputting this line.
Usually, this type of error is caused by power (i.e. power not stable enough and the board keeps resetting), wiring (e.g. incomplete soldering or short-circuited pins) or the existing firmware disabling the JTAG pins (erasing the FLASH memory via esptool.py should take care of that).
If the reset is never issued, please try using both pins 3 and 15 (different debug probes use different reset pin by default). Also make sure the esp8266.cfg file has not been modified and still sets reset_config to trst_and_srst). If you are not sure, you can also delete and reload the ESP8266 OpenOCD package via VisualGDB Package Manager.
Sorry, this looks like an issue of the ESP-IDF itself and not anything specific to VisualGDB. Please consider asking on the ESP32 forum instead.
That said, if you can confirm that the project works as expected outside VisualGDB, but doesn’t work when built with VisualGDB, we can help you configure VisualGDB to match the manual build behavior.
