Forum Replies Created
-
Posts
-
Hi,
Just wanted to share an updated build: http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2451.msi
It now properly supports adding/removing components and source files just like the regular ESP-IDF projects (i.e. it will update the correct ESP-IDF-specific statements, so you won’t need to worry about that). It is still missing support for target property editing, however it should be more convenient than the previous build if you are actively experimenting with the new ESP-IDF.
Hi,
Thanks, we have indeed managed to reproduce this, however it looks like a problem specific to ESP-IDF (regular VisualGDB Linux projects built with CMake work as expected).
Could you quickly recheck whether it reproduces in your setup when running the normal Windows CMake manually or via idf.py? If not, we should be able to analyze the differences on our side and ensure it works as well. If it doesn’t work outside VisualGDB either, it’s likely caused by some constructs inside ESP-IDF itself (e.g. multiple project() definitions) and we would advise either experimenting with internal ESP-IDF definitions, or simply defining PROJECT_VERSION explicitly.
Hi,
Thanks for sharing this and good to know it works. Looks like there might have been another confusion though.
Have you tried using our latest experimental toolchain (http://sysprogs.com/files/gnutoolchains/esp32/esp32-gcc5.2.0-r13.exe, not listed on the download page yet, linked in the post above), or did you download the R12 toolchain listed on the download page?
Thanks for the log. We have rechecked this and it indeed turns out that trying to send a string consisting purely of whitespace characters causes VS to throw an exception.
Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2450.msi. It will filter out empty lines and will also not stop the test session even if the VS refuses to relay the test message.
Hi,
Not fully sure what you meant, but the ST SDKs include a few TCP/IP samples based on the lwIP stack, so we would advise simply cloning any of them via the VisualGDB Embedded Project Wizard.
Hi,
Strange. Our toolchain is a repackaged copy of this archive with the following extra files/directories:
- toolchain.xml
- esp32-bsp
- esp-idf
None of those should be related to any Python issues, so most likely there is some other difference between the toolchain that worked and the current one. Could you please double-check which MSYS2 environment you used originally? If you cannot find it anymore, please try downloading it from scratch from the Espressif site, applying the fix and check if the new ESP-IDF works there. If not, there might be some other step that you performed with the previous checkout.
The “Open Cygwin Terminal here” command was renamed to “Open ESP-IDF Terminal here” in the build that fixed compatibility with the MSYS2 toolchains, so you are likely still using an old build (the officially released Preview 5 doesn’t include MSYS2 toolchain support as we haven’t tested it sufficiently yet). Please try this one: http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2448.msi
Hi,
The code 2 typically indicates a missing file, so it might be caused by some components of the toolchain missing or corrupt. As a quick check, please try running the same command line manually (simply copy the contents of both “executable” and “arguments” to a command prompt window). If it doesn’t help identify the problem, please try reinstalling the toolchain.
Hi,
Unfortunately Resharper has the same problem. As it’s designed to work on top of the VC++ IntelliSense engine, it won’t work properly with the Clang IntelliSense unless JetBrains explicitly adds support for this.
If you are missing any specific features from our Clang IntelliSense engine, please don’t hesitate to share them here. Although it would take some time on our end, we should be able to support many of them if they increase the productivity when working with VisualGDB projects.
Hi,
Sorry for the delay. First of all, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2448.msi. We will considerably improve the usability of the CMake-based ESP-IDF projects – the Solution Explorer will now show more meaningful component structure, the VisualGDB Project Properties will let you edit the KConfig variables and manage checkouts, and the context menu commands for opening terminal and programming FLASH memory will work just like for the regular non-CMake projects.
Please still refrain from adding/removing/renaming sources via Solution Explorer as this logic does not yet support ESP IDF-specific semantics.
Also if you are encountering many “Access Denied” errors, your antivirus might be blocking some of the tools checked by VisualGDB. Please double-check your antivirus logs.
The regular CMake indeed doesn’t provide any special files for storing options. You can pass the options via the CMake command line using the -DNAME=VALUE syntax. VisualGDB stores the command-line arguments it will pass to CMake in the .vgdbsettings files and provides convenient GUI for editing them (right-click on the project in Solution Explorer -> VisualGDB Project Properties). To make it easier, we have added a new setting for specifying those variables directly: VisualGDB Project Properties -> CMake Project Settings -> Extra CMake Configuration Variables.
If you would like to find an IDE-invariant way of storing this settings, we would advise continuing your approach with defining them in a separate .cmake file via the set() commands. It’s hard to say why the ${PROJECT_VERSION} variable would not get handled properly, but dumping it via message() from several places inside the CMake files might help pinpoint the exact place where it gets overridden.
Let us know if you have any further questions and we will be happy to help.
Hi,
Sorry for the delay. We have added very verbose additional logging to the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2448.msi
Please set the following registry value (32-bit DWORD): HKCU\SOFTWARE\Sysprogs\VisualGDB\Settings\ExtraVerboseTestExecutorLogging
Then restart Visual Studio. Next time you run tests, the test output will contain detailed logs for each step performed by the VisualGDB test executor (please first check that you can see the “Initializing test container from …” message). Please share the updated log once you reproduce the ‘The parameter cannot be null or empty’ problem.
The “WriteFile failed” error means that the VS test engine has stopped receiving test information from the VisualGDB debug engine. It can be caused by the same “null” error, or by something else. Please also share the entire verbose output from the VS Test Output window once you reproduce this again. This should help us finally pinpoint the problem and release a hotfix.
Hi,
It looks like your project is missing implementations for some functions, so you would need to locate them and ensure they are added to the project.
If you are not sure about the differences between the declarations and implementations, please try following this tutorial. It explains in detail how to diagnose a similar problem.
Hi,
The GNU linker indeed automatically prepends the “lib” suffix and the “.a” or “.so” extension for libraries specified via the “library names”. You can find an exhaustive description of this logic here: https://visualgdb.com/support/linkerinputs/.
BTW, if both projects are built with VisualGDB, you can simply add the library project to the solution and then add it as a reference to the main executable project (via right-clicking in Solution Explorer) and VisualGDB will handle everything automatically, so you won’t need to worry about the GNU library naming rules.
No problem, we can clarify.
It looks like you have installed the stable version of VisualGDB (5.3) that doesn’t support advanced ESP-IDF projects at all. Please install VisualGDB 5.4 Preview 5 instead.
With the toolchains, there are 2 options:
- You can use our Cygwin-based toolchain. It’s slower than the MSYS2-based toolchain, but provides a more consistent set of Linux-world tools (e.g. python).
- Alternatively you can either use the MSYS2-based toolchain and setup the toolchain XML files manually, or download our experimental R13 toolchain (see the link above) and the corresponding experimental VisualGDB build. This toolchain comes straight from Espressif (with some configuration files from us), is faster than our Cygwin environment, but is prone to common MSYS drawbacks (e.g. the Python issue you discovered). This toolchain only works with the experimental VisualGDB build linked above, as the regular Preview 5 doesn’t contain a few workarounds for other MSYS issues.
Hope this explains. Let us know if you need further help.
Hi,
The pthread library is usually available on the Linux targets, but not on barebone embedded targets like STM32. If your project relies on the pthread library, it might require some specific STM32 port of it. We would advise confirming it with the party that provided you with the project and check what exact libraries they are using.
The other library is likely not found due to the extra extension in the library name list (see the linker log – it’s automatically appending the extension to the name you specified resulting in libTouchP0P1.a.a).
Hi,
No worries. Given the complexity of the ESP32 build tools it’s often not clear what component is causing trouble, so it’s always worthwhile to check with us if you suspect any of our tools might be involved. Although we are not able to solve most problems that are outside our control, we can often help you narrow them down and suggest where to seek further help.
BTW, if you are using the Espressif’s msys2 environment, please consider using the VisualGDB build and a toolchain from this post. The new toolchain is a repackaged version of the original Espressif’s toolchain with the necessary XML definitions for VisualGDB to fully support all ESP32-related features out-of-the-box (you would still need to apply the fix from the Espressif’s forum, but you should be able to use VisualGDB’s GUI to manage ESP-IDF checkouts now).
