Forum Replies Created
-
Posts
-
If GDB recognizes and reports the data via the MI interface, both Visual Studio and VisualGDB will show it out-of-the-box. If the data appears when using the regular VS debugger, but not with VisualGDB, most likely you are using different GDB settings.
If you could capture a GDB log from both VisualGDB and the regular VS debugger, and let us know the variable name in question, we can help you configure VisualGDB to show it the same way the VS debugger does.
We are sorry, as we have explained before, we do not have any plans for supporting it in the watch window and will not be able to change it.
As a workaround, please use the GDB session window. All other functionality provided by VisualGDB will work as expected.
Hi All,
Indeed, uninstalling Visual Studio while VisualGDB is already installed may trigger a few issues in the installer logic. Following our troubleshooting instructions usually helps resolve them very fast.
Hi,
No problem, you can use the GDB session window to send commands directly to GDB, including the ones to evaluate variables via libstdcxx.
Hi,
No problem, you can wrap the contents of the file with #ifndef __SYSPROGS_CODESENSE__. This will effectively hide the file from IntelliSense, while still building it as usual.
Hi,
This looks like an issue between the J-Link and the target and not something VisualGDB-specific. Please consider forwarding the log to Segger support to get more specific advice.
That said, if you can debug the target by running the J-Link gdb server manually, we can definitely help you configure VisualGDB to replicate the same results if you could share the J-Link gdb server command line that does work with this device.
This looks like one of your libraries and not a part of VisualGDB. If it works differently in VisualGDB vs. Arduino IDE, most likely you ended up with 2 copies of it having different versions (or manually edited one of them). Our tutorial on diagnosing Arduino issues explains how to troubleshoot exactly this type of problem.
We have already updated VisualGDB on our side to handle requirements.txt in this case correctly and will include this fix in the upcoming VisualGDB 5.6R2.
Regarding the versions, if we updated VisualGDB to use the latest ESP-IDF with ESP-ADF, instead of the version referenced as a git submodule, it is only a matter of time until the next ESP-IDF update (that was never tested with ESP-ADF) would break everything.
E.g. according to the ESP-ADF documentation, the supported ESP-IDF versions are 3.3.2, 4.0 and 4.1, so the Espressif’s online installer putting together ESP-ADF 2.3 and ESP-IDF 4.3.1 is contradicting their own documentation. It does resolve the bug you encountered, however it might introduce other bugs and it’s generally something for Espressif to figure out and document.
We have provided detailed explanation why VisualGDB uses the ESP-IDF submodule inside ESP-ADF on our documentation page, along with instructions for manually switching the ESP-IDF version. We will not change the default behavior, as it would likely introduce more problems as newer ESP-IDF versions are released.
No problem. We will gladly investigate this issue if any other user with active technical support confirms it.
Regarding the support quality, the VisualGDB product support only covers issues in VisualGDB itself. E.g. if you had an active technical support, this issue would be fully covered – we would explain how to configure VisualGDB to achieve the desired results. This is simply a matter of configuration – no changes on the VisualGDB side would be necessary.
We understand that you have previously requested our technical support to explain specific settings of ESP-IDF and help troubleshoot specific projects that triggered unexpected behavior in ESP-IDF tools. These issues are indeed not covered by our support because we do not control how ESP-IDF is developed and tested. ESP-IDF has its own issue tracker where Espressif tracks, prioritizes and resolves the issues, and we are not able to provide an instant alternative to it as a part of VisualGDB support. Our support can only help if the same functionality works with ESP-IDF directly, and doesn’t work with VisualGDB.
Hi,
Thank you for contacting us. Indeed, your technical support period has expired. Hence we would kindly ask you to renew it here and update to the latest VisualGDB 5.6. If the problem persists, please let us know once you have renewed your support, and we will help you get everything working.
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.
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.
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.
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.
