[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 4 years 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/

[support]

Hi,

As you have pointed out before, you can disable the suggestion popups via Tools->C/C++ (VisualGDB)->advanced->Code Completion->Suggest names while typing.

You can also try setting Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Smart Suggestion List GUI to VS2019+ Native that is somewhat slower than the VisualGDB-provided one, but will work better on high-DPI displays.

You can disable the Code Explorer (Outline and Globals views) by unchecking the “Show window on startup” setting as shown here.

[support]

Based on our experience with ESP32, not all combinations of toolchains and SDKs work together well. Espressif frequently releases updates to the toolchains, ESP-IDF and ESP-ADF, where we pick them up, run a few basic tests and release ready-to-use packages.

Sometimes, these releases contain bugs that are addressed later (e.g. the latest ESP-IDF 4.3.1 breaks projects using mbedtls, and the workaround is to cherry-pick a specific commit from another branch). As Espressif typically fixes the issues relatively fast, we leave it up to them and stick to shipping ready-to-use snapshots of their most recent public releases.

We have designed VisualGDB to be very flexible, so that it can be used with any combination of the tools that works otherwise. If you have a specific version of ESP-ADF and toolchain that work together, you can merge them into our toolchain by replacing the contents of the tools and esp-adf directories, and updating the paths in toolchain.xml. VisualGDB will pick up these paths and will produce exactly the same results as your Eclipse-based environment does, because it will run exactly the same tools with exactly the same arguments. This might require some minor troubleshooting, but since VisualGDB allows dumping the exact command line it uses for building, you can very easily troubleshoot issues by comparing it against another command line that works just fine.

[support]

Hi,

The ESP32 toolchains are provided by Espressif. We merely pick up the stable releases, bundle it together with the latest stable ESP-IDF and run a few basic tests. If you would like to know the difference between 2021r1 and 2021r2, please contact Espressif.

You can download an equivalent of the 2021r1 toolchain from Espressif here: esp32-gcc8.4.0-r3.exe

[support]

Hi,

idf.py is normally included in the toolchain (e.g. sysgcc\esp32\esp-idf\v4.3.1\tools\idf.py and sysgcc\esp32\tools\idf-exe\1.0.1\idf.py.exe). The easiest way to run it would be to dump the project configuration command to a batch file and replace the actual “cmake” command with cmd.exe. This will run the command prompt window with the same environment that VisualGDB would use for cmake (that should be sufficient for most tools). You can then try running idf.py from that window.

Based on the description you provided, it looks like a bug in ESP-ADF that might be triggered by a specific toolchain. If you can confirm that it works just fine in the Eclipse environment (i.e. the generated file can be FLASHed successfully), please try downloading the same toolchain version from our download page and installing ESP-ADF there.

You can also simply replace the contents of the esp-adf directory inside the toolchain with the version that works from Eclipse. If it doesn’t help, you may need to also replace the tools in the tools subdirectory, and update the paths to them inside toolchain.xml.

[support]

Hi,

The “Analyzing references” stage only affects advanced recoloring of the source file, finding references, etc. You can indeed enable lightweight references analysis if you would like to speed it up.

Code suggestions and go-to-definition use a different mechanism that does not involve the “Analyzing references” part.

The debug log looks like the delay comes from gdb and not from VisualGDB itself. Hence, it will affect any debug session that is using gdb and cannot be reduced on the VisualGDB side.

[support]

Hi,

VisualGDB uses the open-source OpenOCD tool to handle hardware-level debugging aspects. The support for ST devices in OpenOCD is contributed directly by ST, so it typically works quite well with most of the boards, including the Nucleo-144 ones.

[Author]

Posts