Forum Replies Created
-
Posts
-
Hi,
Most likely, you are building the deprecated HLA_Multicore platform. Please try switching it to Mainstream via the VS platform selector.
We have also just updated the repository, removing the HLA_Multicore platform completely.
Hi,
According to our records, your support period has expired. Please kindly renew it here and we will help you get everything working.
Hi,
This is an Arduino-based project and not an ESP-IDF-based one. Arduino projects use the Arduino build system that can be considerably slower than CMake+Ninja.
Either way, you can try building the project outside VisualGDB as shown here: https://visualgdb.com/documentation/projects/arduino/#troubleshooting
Thanks for renewing your license. The slow build might come from the GNU Make tool used by the ESP32 projects. Please make sure your project uses CMake and Ninja, and not the legacy GNU Make. You can recheck it via VisualGDB Project Properties -> CMake Build Settings.
If this doesn’t help, please try exporting the configuration and build command lines from VisualGDB to batch files as shown here. Does running them manually also result in a slow build?
Hi,
This looks like a message coming from the ESP32 OpenOCD port that is maintained by Espressif. Most likely, some changes to the project configuration are either incompatible with JTAG debugging, or trigger a bug in OpenOCD.
Our best advice would be to try erasing the FLASH memory via esptool.py and reverting the change that triggered it. If you need further help with this, please consider submitting a bug to the ESP32 OpenOCD repository on Github.
Hi,
Good to know you know what is going on. In general, it is hard to suggest anything specific for a complex project that was created by someone else and involves numerous external points of failure.
If you believe VisualGDB is not working as expected, please try reproducing the problem completely from scratch (i.e. from creating a new project) and sharing the repro steps per our problem reporting guidelines. If we are able to reproduce the issue on our side, and can confirm that it is caused by VisualGDB, we should be able to resolve it.
Sorry, unless we can reproduce the issue on our side, we will not be able to address it. We will keep an eye out for other users reporting similar behavior and will fix it as soon as we are able to reproduce it.
According to our records, your support has expired a while ago. Please kindly renew it via this page and try installing the latest VisualGDB 5.6 Beta 4. If the problem persists, please let us know and we will help you get it working.
Hi,
No problem. In the long term, we will add support for collecting non-critical warnings during the project import, and showing them at the end of the import, however for now, invalid paths will be just ignored.
Placing the project in a correct location should indeed get it imported correctly.
Hi,
No problem, please try this build: VisualGDB-5.6.5.4312.msi
Hi,
Thanks, it looks like the .ewp file references some sources and include directories outside its directory, that resulted in some invalid paths when the project file was moved to a shorter path.
We have updated VisualGDB to skip over invalid paths rather than throwing an exception: VisualGDB-5.6.5.4312.msi.
That said, the project will likely not build until the missing files are manually located and added to it.
Hi,
This could explain it. If the custom target provider would cause the test host process to crash unexpectedly, VisualGDB would indeed display this message.
Our best advice would be to try attaching to the TestHost.exe executable and checking for exceptions. You can also try showing a message box with the current PID from the constructor of your target provider to make attaching easier.
Hi,
According to our records, your support period has expired a while ago. We can gladly point you to the relevant documentation, however we would kindly ask you to renew your support first.
