Forum Replies Created
-
Posts
-
Please try checking whether the project built via command line actually uses the correct partition table file (i.e. whether it flashes successfully via idf.py flash). If the file works just fine (e.g. you can edit it manually and the changes are applied) and the only issue is that the “Partition table” item in Solution Explorer is not working), we should be able to fix it. If the file doesn’t work when the project is built outside VisualGDB, the issue is not on the VisualGDB side, and VisualGDB cannot fix it automatically.
Hi,
There is no special command in VisualGDB to copy/move the files, however you can always copy the files using Windows Explorer first, and then specify the new location in the VisualGDB Project Wizard.
No problem. If the project has loaded successfully, the command would be “Reload CMake project”.
The Eclipse-based environment might be using a different version of ESP-IDF, or a different toolchain, that would indeed produce different results. Please try reconfiguring and building the project via the command line exported from VisualGDB. If it works differently from the build from Eclipse, you can try comparing the 2 command lines, or the SDK versions, so see what exact part is causing the difference.
Hi,
Please try updating to the latest VisualGDB 5.6. If the problem persists, please let us know the updated stack trace.
Hi,
The documentation indeed refers to copying the UF2 file. We are not aware of any other ways to program the Raspberry Pi Pico memory without the SWD pins.
On the VisualGDB side you can automate copying of the UF2 file by creating a custom shortcut (simply use “cmd.exe /c copy …” command to copy the UF2 file to the device), however you would still need to press the BOOTSEL button and reset the device in order to enter the bootloader, unless you can find a programmatic way to do it from your firmware.
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.
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.
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:
- Does the IntelliSense timing view (step 7 of the tutorial) show anything extraordinary? Could you share a screenshot of it?
- 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?
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.
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.
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.
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.
Hi,
No problem, we have a detailed tutorial on optimizing Clang IntelliSense performance: https://visualgdb.com/tutorials/intellisense/performance/
