Forum Replies Created
-
Posts
-
Hi,
Thanks for reporting this, we have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1366.msi
Hi,
First of all, please note that ESP8266 and ESP32 debugging is extremely unreliable and random errors are very common.
We will try to clarify what is going on based on your description. The LIBUSB_ERROR_NOT_SUPPORTED error can actually be safely ignored. OpenOCD shows it as it first tries to connect to the ‘Virtual COM port’ part of the Olimex JTAG probe. If you get your breakpoint to hit, the problem is most likely not related to drivers or JTAG connections, but is caused by one of the tool limitations. We will try to outline them below.
The ESP8266 chip has undocumented watchdog mechanisms that can break debugging if the chip is stopped at a breakpoint for too long. Our OpenOCD port disables the known watchdog, but sometimes the chip still goes to an undebuggable state.
The chip also has only one hardware breakpoint, so you cannot set more than 1 breakpoint in FLASH code. Furthermore, when you step through the code with F10 or F11, gdb internally uses an extra breakpoint, so in order for that to work reliably, you need to remove all other FLASH breakpoints. We usually recommend moving the functions you want to debug to RAM.
Another problem is that the ESP8266 chip sometimes enters some undocumented state where it does not respond to debug requests via JTAG. This happens when using the AT command firmware, but may happen with other functions as well.
Our general recommendation would be to understand what debugging functionality works (e.g. setting breakpoints only in RAM) and rely on it to debug.
Hi,
This looks like a conflict between files generated by VisualGDB wizard and the files imported from CubeMX.
The ‘multiple definition’ error can be resolved very easily by unchecking the ‘default system file’ checkbox on the Embedded Frameworks page of VisualGDB Project Properties.
The ‘external dependencies’ list is derived by Visual Studio by trying to locate included headers, so it can be incorrect, but this should not affect compilation or IntelliSense.
Hi,
Sorry about that. We’ll keep a track of this and if we get more similar feedback, we will add a simple key-value based view as well.
Hi,
It’s hard to promise anything definitive currently, but we will be adding some sort of Clang-powered code analysis in one of the next major VisualGDB releases.
Hi,
Thanks, we have managed to reproduce and fix this. We have updated the code example in the post above and will ship the correct code in the next STM32 BSP.
Hi,
Yes, that can be indeed tricky, but VisualGDB should normally be able to setup everything automatically so you wouldn’t need to worry about complex toolchain issues.
Hi,
It is hard to say why X11 is slow. VisualGDB simply uses the libssh2 library to forward X11 traffic inside the SSH channel, so this definitely adds compression and encryption. Perhaps this is responsible for slowdowns as well. By setting DISPLAY to hostname:0.0 you instruct the graphical applications to connect directly to your Windows PC, so as long as your firewall supports it, this should work as well and may be faster.
The XML errors you mentioned should definitely not happen, so feel free to post details here so that we could investigate and fix them.
Hi,
Unfortunately this is currently not possible as VisualGDB uses rich GUI to present various settings (e.g. command lists) and merging settings from different configurations there would greatly overcomplicate the design. The only workaround we could offer is to programmatically edit the .vgdbsettings files.
Hi,
You may have purchased the Linux edition then. You can always upgrade it here: https://sysprogs.com/splm/mykey
Also if you don’t need to copy this file each time, you can simply upload it once with SmarTTY and keep on using the Linux edition.
Hi,
If you want to upload a text file to the target before debugging, you can add a new upload action to the custom pre-debug actions on the Debug Customization page of VisualGDB Project Properties (requires Custom edition or higher).
Hi,
First of all, please try the latest VisualGDB 5.2, as it contains fixes for many issues found in v5.1.
The behavior you described with deleting .user files looks like a bug. Please check if you can still reproduce it with v5.2. If yes, please let us know the steps to reproduce it and we will investigate it.
Hi,
Most likely either you modify some global header file used by all other headers, or VisualGDB believes it is modified and does a full rebuild.
Please try opening the Clang IntelliSense Diagnostics Console and check for messages like thi:
[+0:00:33.084] Found an outdated PSF 0 due to <file> during initial check. It will be re-built
It should explain why VisualGDB reparses the files.
The Error List behavior is by design – showing all errors from the entire project would require constantly rebuilding all the files in the background. Currently VisualGDB only does that when you use the ‘Go to definition’ or ‘Find all references’ commands.
Hi,
VisualGDB should not interfere with this command. If you believe it does, please try reproducing this with one VisualGDB-based and one non-VisualGDB based projects and post screenshots here. We should be able to investigate it based on that.
