[support]

Hi,

This looks like a bug in the ESP-ADF itself. Please try building the project outside VisualGDB as described here. If the problem persists, it is not specific to VisualGDB and likely requires a patch to ESP-IDF or ESP-ADF. If the problem only happens when using VisualGDB, please let us know more details and we will help you configure VisualGDB to replicate the results of the manual build.

EDIT: We have updated our ESP32 Documentation explaining the relations between ESP-ADF and ESP-IDF, and how they could cause this type or problems.

• This reply was modified 3 years, 8 months ago by support. Reason: added link to the updated documentation

[support]

Hi,

Thanks for providing us the additional details. It looks like you are using the older VisualGDB build that is indeed not fully compatible with the latest ESP-ADF.

We have just released VisualGDB 5.6 that addresses this issue, and introduces many new features. Please feel free to update to it.

[support]

Hi,

Thanks for the update. The delay between “Doing a CodeComplete run with minimal reparsing” and “Exporting parse results” is the time that Clang takes to parse the source file and determine the symbol referenced at the requested location.

Normally, it should take roughly the same time as the regular code completion (Ctrl-Space) does, that is typically under 1 second. If it takes longer, most likely, the precompiled headers or preambles are not working properly. We can help you get it working if you could check a few additional things:

1. Does the IntelliSense timing view (step 7 of the tutorial) show anything extraordinary? Could you share a screenshot of it?
2. Does code completion (Ctrl-Space) work faster that Go-to-Definition? Is the speed the same for unscoped completion (e.g. int main() { <HERE> }) vs. scoped completion (std::<HERE>)? Could you attach the snippets from the Clang IntelliSense log corresponding to the scoped and unscoped code completions?

[support]

Hi,

Programming via COM port does not utilize JTAG or OpenOCD. It simply uploads the image to the built-in bootloader using esptool.py. You can achieve the same effect with VisualGDB by right-clicking on the project in Solution Explorer and selecting “Program FLASH memory”.

In order to do JTAG debugging, VisualGDB uses the OpenOCD port maintained by Espressif. If it doesn’t work with your hardware, please refer to the documentation from Espressif to get it working.

If you can confirm that OpenOCD works outside VisualGDB, but not when used by VisualGDB, please let us know the email address associated with your license, and we will gladly help you configure VisualGDB to replicate the results of running it manually.

[support]

Hi All,

@paulh001, thanks for suggesting it.

@Sam_a, you can find more information about OpenOCD and drivers on this page.

[support]

This happens when the Clang IntelliSense process crashes and VisualGDB automatically restarts it. If it always happens after a “Reparsing C:\User_jof\CPP_LINUX\R3layPI\AudioManager.cpp” line, please feel free to attach a dump file produced after the crash, and we will investigate it.

[support]

Hi,

The regular VC++ IntelliSense is implemented by Visual Studio itself. VisualGDB provides it with the list of include directories and preprocessor macros from your projects, but it cannot control how it handles things internally. Depending on the project structure (or some project-specific parameters) it indeed may not work correctly. This was one of the reasons we developed the Clang IntelliSense as a replacement to it.

If you can point out specific cases where the Clang IntelliSense doesn’t work as expected (e.g. Go to Definition not working), we can gladly investigate it further.

In general, Go to Definition requires an up-to-date symbol cache (i.e. list of all symbols and relations between them). It usually takes a few minutes to build initially, but unless you frequently change the common headers used by all other files, accessing it should be almost instantaneous. Again, if you can provide a few examples when it’s not working this way (with the rough timing or a screen recording), we will be very happy to look further into it and help you get it working.

[support]

Hi,

Clang IntelliSense works differently from the regular VC++ IntelliSense. The regular Visual Studio’s IntelliSense parses the code using a faster, but less accurate method. This results in faster initial performance for huge projects, but produces less accurate results for complex cases.

The Clang IntelliSense always does a 100% accurate parse of the code (as if it was being compiled), and hence can extract precise information about the code structure, powering features like CodeJumps, Code Explorer, etc. Due to the complexity of the Clang codebase, it indeed sometimes crashes when it encounters incomplete code. Our IntelliSense engine is designed to seamlessly recover from these crashes without losing any data, so you can continue developing your project as usual, even if the engine has crashed. If it repeatedly crashes at exactly the same position, please feel free to attach the dump file it produced here, and we will investigate it further.

The #pragma once warning issued by Clang can be safely ignored. Alternatively, you can indeed switch to using include guards if you wish to eliminate the warning.

[support]

Hi,

No problem, we have a detailed tutorial on optimizing Clang IntelliSense performance: https://visualgdb.com/tutorials/intellisense/performance/

[support]

Hi,

We have just rechecked the package and it worked just fine. Please make sure your antivirus is not interfering with the package installation, and that your VisualGDB installation, or the package file is not corrupt.

[support]

Hi,

Most likely, you have picked up an incorrect remote machine in the “Transfer directory” action. Please double-check all the action settings.

If this doesn’t help, please make sure you can reproduce the problem on a project created from scratch, and then share the steps we can follow to reproduce it on our side. Please make sure you include the relevant screenshots, as otherwise we won’t know what exact settings you have changed.

[support]

Thanks very much for sharing this!

[support]

Good to know it works. We usually want to minimize the changes to the GCC sources when building our toolchains, because it often has unforeseen side effects (e.g. increasing the size of one buffer could prevent something else from being allocated).

The difficulty of patching would depend on how many assembler instructions would be affected by the change, and how difficult would it be to locate them. From a very brief look into the source, it looked like it would only affect a couple of instructions near public API calls, so it’s easy to find them.

Either way, feel free to share the bytes you changed in the executable, so that other users could replicate it if they run into anything similar before we release a 64-bit toolchain.

[support]

Thanks for sharing this and good to know it works.

[support]

Please note that VisualGDB focuses on improving the typical development scenarios that would otherwise take a lot of our customers’ time. E.g. we provide a powerful Clang-based IntellISense engine that allows exploring large code bases, more reliable debugger integration, convenient GUI for configuring common settings, deep integration with Valgrind, CMake and numerous other tools, etc. You can find more about VisualGDB features for Linux here.

If none of these features made VisualGDB worthwhile for you in 6 months, adding support for visualizing a very specific container will not make much of a difference. So instead, we have to focus on features that would make a difference in the context of common tasks (e.g. the newly added Code Explorer is a huge help when dealing with large projects).

[Author]

Posts