[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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:

1. 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.
2. 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.
3. Once we are confident with the quality of the recently introduced features, the beta branch becomes the stable branch.
4. Once the stable release is out, we release updates to the BSPs, toolchains, etc., that were not released in parallel with the product development.
5. 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.

[support]

Thanks for confirming your license key. We have linked it to your forum profile.

Profiling the PicoSDK-based projects indeed requires a bit of additional setup. We have just published a tutorial explaining everything step-by-step. Feel free to follow it and use it as a working reference. Please make sure you are using the latest VisualGDB 5.6 release (not the Beta).

The Chronometer relies on the DWT cycle counter in order to determine how much time has passed between events. It will indeed not work if any part of your code (e.g. the instrumenting profiler) also uses it. You can find out the exact GDB commands used by VisualGDB to read and reset the cycle counter by checking the C:\Program Files (x86)\Sysprogs\VisualGDB\TimestampProviders\DWT.xml file.

• This reply was modified 3 years, 8 months ago by support.

[support]

Hi,

Thanks, we are aware of this. It is caused by a limitation of Clang 6.0 used by our IntelliSense engine. We are planning to move to the latest Clang 13.0 in the next major version of VisualGDB, that should resolve the issue.

[support]

Hi,

No problem. Please let us know the email address associated with your license, and we will be happy to walk you through everything.

[support]

Hi,

You can disable Code Explorer using the “show window on startup” setting in the settings popup on top of the window.

[support]

Partial. VisualGDB 5.6 introduces RefactorScript – a mechanism for scripting non-trivial code generation (e.g. generating constructors based on the field list). It currently supports analyzing classes, methods, enums and variables, as well as generating new code, and comes with 12 ready-to-use scripts for various common scenarios.

Using it to extract functions would require statement-level information, and a method for moving/editing code, that is not available yet. We will listen to the feedback on RefactorScript and will try to extend it to support these, and other scenarios. In the meanwhile, feel free to try out VisualGDB 5.6 and share the feedback you have on RefactorScript.

Edit: we have just published a tutorial showing RefactorScript in action step-by-step: https://visualgdb.com/tutorials/intellisense/refactorscript/

[Author]

Posts