Forum Replies Created
-
Posts
-
Thanks for the update. It looks like the connection succeeds, so the error might be caused by something else.
Please try switching the GDB Session log to “All GDB Interaction” and check the GDB output for a specific error.
If you are not sure, please create a full gdb session log and attach it here so that we can review it.
Sorry, this fix isn’t a part of the official release yet, as we will be bundling it together with a few other small improvements. We expect to release the updated version in the end of this week, or the beginning of the next one.
Hi,
We have recently finished investigating this and added logic for automatically correcting invalid file references. Please try this build: VisualGDB-5.4.111.3240.msi
Hi,
This could happen if an old instance of OpenOCD was still running in the background, preventing the new one from listening on port 3333. As an experiment, please try changing the port (by adding -c “gdb_port 1234” to OpenOCD command line) and update the gdb settings accordingly. If this solves the problem, please double-check that the old OpenOCD instance terminates successfully and that no other program is holding the TCP port open (you can use the netstat tool to do that).
You can also troubleshoot this by starting OpenOCD and trying to telnet to its TCP port. If the connection fails, try disabling the firewall as it sometimes incorrectly prevents programs from connecting to OpenOCD.
Sorry, unfortunately it’s hard so suggest anything specific without knowing the exact steps to reproduce it, as there are too many factors that could be causing this.
Our best advice would be to try creating a similar project from scratch (same type, same toolchain, etc), and try comparing the behavior between them. E.g. add the same “hello, world” source file to both test project and the big project and if it behaves differently, try reducing the big project until it matches the small one (e.g. by removing files and settings from it). Once you pinpoint a specific setting that causes the problem, we should be able to suggest a workaround, or provide you with a hotfix.
Installing VisualGDB 5.4R11 should normally be sufficient, so the problem is likely caused by something else. Would you be able to create a short video showing the problem (from creating a project via the wizard to having no Ctrl-Click functionality available)? Alternatively, please describe the exact steps to reproduce it (including every choice you make in the wizard and the screenshots of the VS window with the editor where Ctrl-Click is not working).
Hi,
Based on the information you provided via the support form, a trial has been successfully started on that computer under a different user account on 2019-06-06 14:23:36 and has indeed expired. Hence the message you are observing is by design.
Hi,
Most likely, some incomplete construct in one of the template functions in your code is triggering some bug in Clang. VisualGDB is designed to run the Clang IntelliSense in a separate process and make sure that those crashes don’t result in losing any work, but we should be also able to patch the corresponding Clang logic to fix it. Please send us a minidump file via the support interface and we will get back to you with more details.
Hi,
Normally, just adding a config file should be sufficient, however there could be several factors interfering with it. Please try reopening the solution file to reset all caches; if it doesn’t help, please check whether the new configuration entries appear in the command-line configuration interface (right-click on the project in Solution Explorer -> Open MinGW shell -> make menuconfig). If not, please check with Espressif whether the ESP-IDF version you are using requires some additional steps (or try comparing your project with one of the samples that has custom KConfig files).
If the entries appear under make menuconfig, but not with VisualGDB, please let us know your esp-idf version, your project type (Make/CMake) and the exact steps to reproduce it (if the problem can be reproduced by adding a KConfig file to a basic ledblink sample, please archive and attach the project demonstrating the issue) and we should be able to fix it promptly.
As mentioned above, this looks like an incompatibility between the OpenOCD FLASH driver and the custom FLASH programming code you are using.
As both of those components are external to VisualGDB, unfortunately is it not covered by our product support. Please consider contacting ST support for further help on this.
Hi,
The easiest way to get this to would would be to manually add the source directory containing the files to VisualGDB project properties -> Extra Source Directories.
We understand that it is an extra configuration step and will update VisualGDB to do it automatically in the next major release along with other mbed-related improvements.
It looks like some specific part of your code is triggering a bug in Clang (it fails to resolve an incomplete template). The easiest way to fix this would be if you could narrow it down to a specific combination of headers and send them to us along with the repro instructions. If this is not possible, we can send you a special diagnostic build of the Clang engine that will help us pinpoint and fix the problem based on the crash dump.
It is hard to say what exactly is going on, as VisualGDB uses an external tool (OpenOCD to program the FLASH memory and manage debugging), but most likely you set some FLASH attributes (e.g. sector protection) to a state that would prevent OpenOCD from reprogramming it.
Unfortunately, we are not able to review your projects as a part of our regular product support, however we can suggest some relevant documentation:
- You can read about OpenOCD’s commands for managing FLASH memory on this page.
- You can build OpenOCD from source code and step through it as shown in this tutorial.
Please also feel free to check on the ST’s forum. The OpenOCD’s FLASH memory driver for most of the STM32 devices was contributed by ST engineers, so they might be able to explain what is going on.
Hi,
Most likely the problem is caused by some configuration change on your side and is not related to the update.
Please try narrowing down the problem to a specific sequence of steps that doesn’t work (see the 3-step reporting guidelines here) and we should be able to help you get it to work.
