Forum Replies Created
-
Posts
-
Hi,
No problem, happy to clarify. A few years ago Google switched from distributing the Android SDKs/NDKs independently to having Android Studio automatically install them. Hence, on the VisualGDB side we support 2 workflows:
- The legacy Ant-based workflow using NDK R12 and an older SDK version that can be still downloaded separately. It is recommend for targeting legacy devices, or for building legacy projects created with the Ant tools.
- The new Gradle-based workflow. It involves installing the NDK/SDK via Android Studio and configuring VisualGDB to use them. You can then either import an Android Studio project as shown here, or create a new project using Gradle via VisualGDB Android Project Wizard. The new workflow utilizes the new Advanced CMake Project Subsystem, allowing to intuitively manage projects with large C/C++ code bases.
The location of the Gradle, and the exact syntax varies between Android Studio versions and we periodically update VisualGDB to match it. Following your support inquiry we have started rechecking it with the latest Android Studio 2020.3.1 and will post a link to the updated VisualGDB build here and in the support inquiry you created in the next couple of days.
GDB and LLDB work differently on different devices, so we advise trying both options to see what works the best with your setup.
The socket issue with gdbserver might be caused by the permissions on your device. Please see this tutorial for a detailed explanation of a workaround.
Hi,
No problem, if the verbose mode is interfering with the unordered_map visualization, you can turn it off via VisualGDB Project Properties -> Advanced GDB Settings -> Request verbose output from GDB.
If it doesn’t help, please make sure the native VS log does include the used GDB command line and the full output from gdb (including commands like -var-create –frame 0 –thread 1 – * “m”). Any differences in the watch window contents come from different output from -var-list-children and the only way to troubleshoot them is to understand what is causing this difference.
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.
