Forum Replies Created
-
Posts
-
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.
No problem and thanks for confirming it. Most likely, the problem is caused by some differences between the VisualGDB toolchain and the manually imported toolchain. So our first advice would be to try downloading one of our older toolchains that has the same ESP-IDF version number.
If it doesn’t help, please try importing the toolchain that works into VisualGDB as shown below:
- Copy the toolchain.xml file from one of our toolchains into your toolchain directory and replace the revision number in it with 1000.
- Make sure the BinaryDirectory and Prefix elements in toolchain.xml makes sense (they should point to the toolchain’s binaries same way the do for our toolchain).
- Copy the entire esp32-bsp subdirectory from our toolchain into the imported toolchain
- Copy the IDFCheckouts.xml file from our toolchain and edit it to have the correct ESP-IDF version and the correct relative path to the directory where you have ESP-IDF. This will make sure VisualGDB sets the environment correctly. You can add “(manual)” to the ESP-IDF version to distinguish it in the VisualGDB GUI.
- Finally, open VisualGDB Project Properties for your project, locate the toolchain selector and click “Import a toolchain by locating its gdb” and point VisualGDB to the toolchain.xml of the manually imported toolchain.
- Make sure you have the correct ESP-IDF version selected as well. It should match the version specified at step 4.
If you still get different results from the manual build, please locate the command line in the VisualGDB build log (shown in cyan), right-click on it and dump it to a batch file. It will save the environment set by VisualGDB when launching the build command, so you can compare it side-by-side with your own batch file and produces correct results. Eliminating half differences at a time and checking if the results are still different should help find the root cause in just a few steps.
Let us know if you encounter any issues along the way. Helping you getting equivalent results to the manual build is fully covered by our support and we will be happy to help.
Hi,
The property sheets would still work with VisualGDB (as long as you are using MSBuild), however the VS GUI for editing them may indeed not work, as it appears to be specific to the regular MSBuild backend.
The easiest way to add meaningful settings to a property sheet would be to first set them on a specific project, and then copy the <ItemDefinitionGroup> items from the project to the property sheet (do not forget to remove the conditions).
For a quick example, please consider creating an embedded project (e.g. MSP432) and check the .props file created in the project directory. It will be a property sheet containing device-specific settings imported into the project.
Hi,
This looks like an issue specific to ESP-IDF and not something VisualGDB-specific. Please try building and programming the project via command line and check if the problem persists.
If yes, please contact Espressif for support. If not, please let us know more details (build logs and the output from the device when building manually vs. with VisualGDB) and we will help you configure VisualGDB to replicate the results of the manual build.
