Forum Replies Created
-
Posts
-
This looks like one of your libraries and not a part of VisualGDB. If it works differently in VisualGDB vs. Arduino IDE, most likely you ended up with 2 copies of it having different versions (or manually edited one of them). Our tutorial on diagnosing Arduino issues explains how to troubleshoot exactly this type of problem.
We have already updated VisualGDB on our side to handle requirements.txt in this case correctly and will include this fix in the upcoming VisualGDB 5.6R2.
Regarding the versions, if we updated VisualGDB to use the latest ESP-IDF with ESP-ADF, instead of the version referenced as a git submodule, it is only a matter of time until the next ESP-IDF update (that was never tested with ESP-ADF) would break everything.
E.g. according to the ESP-ADF documentation, the supported ESP-IDF versions are 3.3.2, 4.0 and 4.1, so the Espressif’s online installer putting together ESP-ADF 2.3 and ESP-IDF 4.3.1 is contradicting their own documentation. It does resolve the bug you encountered, however it might introduce other bugs and it’s generally something for Espressif to figure out and document.
We have provided detailed explanation why VisualGDB uses the ESP-IDF submodule inside ESP-ADF on our documentation page, along with instructions for manually switching the ESP-IDF version. We will not change the default behavior, as it would likely introduce more problems as newer ESP-IDF versions are released.
No problem. We will gladly investigate this issue if any other user with active technical support confirms it.
Regarding the support quality, the VisualGDB product support only covers issues in VisualGDB itself. E.g. if you had an active technical support, this issue would be fully covered – we would explain how to configure VisualGDB to achieve the desired results. This is simply a matter of configuration – no changes on the VisualGDB side would be necessary.
We understand that you have previously requested our technical support to explain specific settings of ESP-IDF and help troubleshoot specific projects that triggered unexpected behavior in ESP-IDF tools. These issues are indeed not covered by our support because we do not control how ESP-IDF is developed and tested. ESP-IDF has its own issue tracker where Espressif tracks, prioritizes and resolves the issues, and we are not able to provide an instant alternative to it as a part of VisualGDB support. Our support can only help if the same functionality works with ESP-IDF directly, and doesn’t work with VisualGDB.
Hi,
Thank you for contacting us. Indeed, your technical support period has expired. Hence we would kindly ask you to renew it here and update to the latest VisualGDB 5.6. If the problem persists, please let us know once you have renewed your support, and we will help you get everything working.
Please try commenting out the last line (with the ${IDF_PATH}) in the c:\SysGCC\esp32\gcc840gdb810r6\esp-adf/v2.3\esp-idf\requirements.txt file. This should get past the error message and let you create the project.
No problem, we have added a section about ESP-ADF to our ESP-IDF documentation page, explaining what is done differently, and the rationale behind it.
Hi,
vgagent.exe is often blocked by antivirus software as a false positive. You can read more on this page: https://visualgdb.com/documentation/falsepositives/
Please consider reporting it as a false positive to your antivirus vendor and/or adding vgagent.exe to the exception list. Please also feel free to let us know the antivirus you are using, so that we could update our knowledge base.
Thanks for confirming your license key, we have linked it to your forum profile.
Regarding the build error, most likely, the Arduino IDE and VisualGDB ended up using different sets of Arduino platforms or libraries. As multiple components of Arduino ecosystem are managed by different maintainers, some combinations of platform/library versions do produce invalid results.
We have a very detailed tutorial showing how to capture the build command line from both Arduino IDE and VisualGDB, and how to adjust the VisualGDB settings to ensure it uses the same libraries as the Arduino IDE does.
Hi,
Indeed, since the ESP-ADF installation includes its own copy of ESP-ADF, VisualGDB simply reuses it. However, as you have pointed out, the latest version of the ESP32 Eclipse environment ignores it and explicitly references the ESP-IDF checkout that is installed separately.
The easiest way to replicate the results from the Eclipse-based environment would be to go into the C:\SysGCC\esp32\esp–adf\v2.3\esp–idf folder and run “git checkout v4.3.1” followed by “git submodule update –recursive“. We have also created a Github issue suggesting that Espressif updates the ESP-ADF->ESP-IDF reference to match what is fetched by the online installer.
Hi,
This error means that VisualGDB is not able to launch the J-Link GDB server. Please double-check the J-Link path specified in VisualGDB Project Properties -> Debug Settings. It must be valid and must contain the JLinkGDBServerCL.exe file. If the file does exist, please try disabling your antivirus software – sometimes it would block arbitrary executables from running.
Hi,
No problem. Please try opening Tools->VisualGDB->Manage VisualGDB Packages -> Updates. This will refresh the VisualGDB package cache, and the 1.3.0 SDK will appear in the SDK list.
Please also make sure you remove any incomplete SDK downloads to reduce the chances of confusion.
Hi,
This is by design. The project contains an error and VisualGDB displays it. Please fix the errors in the project first, and make sure you can build it outside VisualGDB. Once this is working, the project will work with VisualGDB as well.
Hi,
No problem. The issue with the partition editor GUI is within our control, so we have updated VisualGDB to support the syntax used by ESP-ADF. Please try this build: VisualGDB-5.6.101.4473.msi
The bootloader issue is somewhat trickier. When you install ESP-ADF via VisualGDB, it simply clones the corresponding tag from the https://github.com/espressif/esp-adf repository, that references ESP-IDF is a submodule. Due to the reasons unknown to us, even the latest ESP-ADF releases reference the old ESP-IDF 3.3.2, although we have heard of other users being able to build it with newer ESP-IDF versions.
You can try checking out other ESP-IDF versions for use by ESP-ADF by manually going to sysgcc\esp32\esp-adf\v2.3\esp-idf and running “git tag” followed by “git checkout <tag name>“. That said, this is something to do entirely at your own risk. Each IDF/ADF combination may work differently, or may not work at all. Also, the workarounds you may discover for ESP-ADF v2.3 may no longer work for the next ESP-ADF release. Finding out the versions used in your Eclipse-based environment (via “git branch”) and checking out the same versions into our toolchain could be a good starting point.
Hi,
No problem, we will clarify. We usually release a major version every year, with many smaller beta/bugfix releases in between, following the cycle below:
- We pick the features from the backlog based on the number of users that would be interested in it, and their impact. We run some internal tests and assess the feasibility/complexity.
- We then release a few beta versions, gradually introducing the new features (and often, new bugs) and rely on the beta feedback to perfect them.
- Once we are confident with the quality of the recently introduced features, the beta branch becomes the stable branch.
- Once the stable release is out, we release updates to the BSPs, toolchains, etc., that were not released in parallel with the product development.
- Until we are ready to introduce the next beta, we publish bugfix releases (R2, R3, etc.) that resolve issues and introduce smaller and less riskier features.
Sometimes, features initially considered for a major release get delayed and grouped with other features. E.g. we have received many requests for different smaller smart tags (e.g. generate C++ operators) and ended up introducing RefactorScript – a universal mechanism that allows defining custom code generation patterns, rather than having a hardcoded smart tag for each specific case. In general, we look for the number of users that could be interested in a specific scenario, and by how much their productivity will be improved by a certain feature.
Currently, we have just released stable VisualGDB 5.6 that includes most of the features requested earlier. We are now working on a few BSP updates and new device family integrations. We will then proceed with the internal experiments on a few major features, and once their complexity and possible drawbacks are clear, we will begin rolling out beta versions and gathering feedback.
When it comes to updating the Clang engine, it usually results various minor glitches, that take some trial and error to get resolved. We will analyze the changes in the latest Clang 13.0 during the next few months (the exact timeframe depends on the feedback on other features and the number of BSP-related changes) and will either assign a specific timeframe to it, or will push it to the next version. Based on our current understanding, the glitches arising from the currently used Clang 6.0 have relatively simple workarounds, so it is not a high priority. If this is a blocking issue for you, please let us know and we will try to assign a higher priority to it.
