Forum Replies Created
-
Posts
-
Hi,
Thanks for updating your forum email. This looks like a known bug in the master branch of the ESP-IDF. When building with CMake on Windows, it tries running the Python script directly instead of using the toolchain’s python executable. As a result, the script doesn’t work properly.
You can reproduce this outside VisualGDB by building the project with idf.py (wrapper for CMake/Ninja build).
The easiest workaround would be to use GNU Make instead of CMake for affected projects until Espressif fixes the issue.
Hi,
Sorry about that. If you could share more details about the crash (whether VS itself or the Clang IntelliSense engine crashes, what is the call stack of the crash or any associated error messages) we should be able to suggest a workaround or provide a fix.
Hi,
It looks like the floating license data has not been loaded properly. Please try restarting Visual Studio and check the Help->About VisualGDB window again.
Please also ensure that your antivirus is not blocking SessionServer.exe – the process responsible for sharing the floating session keys between multiple VisualGDB instances on the same machine. We had a similar issue reported by another user and it turned out their antivirus was silently preventing VisualGDB from reading the shared memory block from SessionServer, so it didn’t trigger any error immediately, but the loaded keys were zeroed, causing a NullReferenceException.
Hi,
Unfortunately this is not possible, as the regular VC++ IntelliSense is closely tied to the regular VC++ project engine and hence will not work with the Advanced CMake engine that is completely different.
That said, if you could share the exact repro steps of the problem you mentioned and we could reproduce it on our side, we should be able to understand why does Clang IntelliSense get slow and either fix it, or suggest a setting (e.g. IntelliSense-only precompiled header) that will radically improve the performance.
Hi,
First of all, thanks for reporting the broken link for the kgdboe download.
Second of all, KGDBoE will likely not work with Raspberry Pi (or may work very unreliably). Please try using a JTAG debugger instead as described in this tutorial.
We have also updated the documentation page for the supported debug methods to reflect the advantages and limitations of various debug methods. Hope this explains. Let us know if you have any further questions.
Hi,
This does look like a bug. We should be able to fix it, however it look like your support period has expired. Please renew your key here and we will investigate and fix this issue.
Hi,
Looks like your support period has expired. Please renew your key here or let us know the updated email if you have purchased a different one and we will help you resolve this.
Hi,
Please try using the VisualKernel Project Properties -> Module Build Settings -> Kernel Symbols for Debugging setting. It will allow caching the symbols/sources for the new kernel and using them for debugging the module.
Hi,
v3.2 and master are different branches of the ESP-IDF repository maintained by Espressif. Please contact Espressif for details on differences between specific branches.
VisualGDB is designed to work with any branch of the ESP-IDF framework as long as it can be built using command line, hence it does not require any porting on our side. Our toolchains indeed include pre-downloaded releases of the ESP-IDF framework, however they come straight from the Espressif’s github repository and are not modified by us in any way.
Perhaps some of the native ESP8266 tools also only work on 64-bit targets? Please try building the failing project manually from the Arduino IDE. Does it build successfully?
If yes, please try comparing the Arduino-builder command lines from VisualGDB and the Arduino IDE (you can use Process Monitor to find out the command line used by the Arduino IDE). Let us know if you notice any differences and we will help you configure VisualGDB to work around them.
Hi,
Based on a quick look, it looks like someone ported the MSP430 gdbproxy to work with AVR devices. However, based on the project stats (0 issues, 0 releases, 4 commits), it is likely in the proof-of-concept stage and may not work reliably at all.
If you would like to try it out with VisualGDB, you can build it and use the “Custom GDB Stub” setting in VisualGDB debugging properties, however if you are not prepared to troubleshoot the problems of the gdbproxy itself, we would not advise doing that and we would recommend using the more popular AVaRICE tool (included in our AVR toolchain).
Please try deleting the %LOCALAPPDATA%\VisualGDB\ArduinoSettings.xml file to reset all Arduino-related settings.
If this doesn’t help, please also delete the %LOCALAPPDATA%\Arduino15 folder and let VisualGDB re-download the necessary packages.
Looks like the Linux machine you are using for building is not compatible with the Raspberry Pi toolchain. Please ensure you use a 64-bit Linux machine for building the Raspberry Pi kernel.
Hi,
Good to know the sysroot sync works.
The library-related options used by GCC can be indeed very misleading, so please feel free to look through this page for an overview and examples. Also feel free to share the error messages you get and the settings you have and we can point you to the right direction.
