Forum Replies Created
-
Posts
-
Hi,
Please try updating to the latest VisualGDB 5.4R5. It includes multiple ESP-IDF-related updates and might fix this issue. If it doesn’t help, please let us know the updated stack trace and we will investigate this.
According to our records, it looks like your trial period has expired. In order to get further technical support, please consider purchasing a license.
Please note that installing VisualGDB on another PC, editing registry to affect the trial counter, or creating further forum accounts does not reset your trial period from the support point of view.
As providing quality technical support for our users requires continuous effort on our side, we do expect our users to play fair and are not able to offer any help once the original trial period expires.Hi,
It looks like your ESP8266 Arduino core might be corrupt. The easiest way to fix this would be to delete it and let VisualGDB automatically download the latest version of the core and all related tools.
Hi,
It looks like a missing reset signal (in our experiments, some probes had to use the TRST signal, while others needed SRST), so trying a few reset options in OpenOCD configuration script might resolve this. If not, please try using Olimex ARM-USB-OCD-H (we have fully tested it on our side and covered in our tutorials), or some of the ESP32 boards with on-board JTAG, that should have the necessary wiring and matching configuration scripts.
Hi,
The exact reason behind this would depend on the project type (e.g. Make/MSBuild/CMake), so it’s hard to say anything without knowing more details.
Our best advice would be to try following the steps described in this tutorial to check the paths and then post the details here with a screenshot of the setting(s) that don’t look right. This should help us understand what is going on and help you get it to work.
Hi,
Based on what you have described, the following events take place:
- You have created a non-relocatable project based on the STM32CubeMX project sample instead of the regular relocatable project shown in the wizard.
- As the non-relocatable project hardcodes the paths to source/header files in the .vcxproj file instead of using the $(BSP_ROOT) variable, it does not open on another machine.
- Per your feedback, we have patched VisualGDB to use the correct $(BSP_ROOT) syntax when creating new projects based on STM32CubeMX and provided instructions on adjusting the project manually.
The most likely reason why the project would still not build on the other machine is because it still uses incorrect paths for some of the files. The only way to diagnose this would be to look through the build log (View->Output), locate the “cannot find source file <file>.c” message, and then search the .vcxproj file for the reference to the file mentioned in the error. Most likely this reference will still use incorrect format and updating it to use $(BSP_ROOT) should solve the problem.
If you do not want to edit the .vcxproj files manually, please consider using the same project types as shown in our tutorials until you get familiar with VisualGDB settings and constraints. We publish those tutorials specifically to help new users find the working combination of settings for their setup and we always advise using them as a starting point.
Thanks for the update. If both OpenOCD and J-Link don’t recognize a specific device on a specific machine, it’s likely caused by some low-level USB driver issues. We understand that the ST-Link tool works with it, however it might be using a slightly different underlying API. Generally, using a different machine, or connecting the device to a different USB port/host controller should work around the issue.
The delay ultimately happens because Visual Studio needs to run certain commands from the GUI thread (i.e. won’t continue or respond to commands until the command is completed) and those commands altogether take a lot of time due to a slow network connection. VisualGDB does show a “command in progress” window when a command doesn’t respond for 2 seconds or longer, however this doesn’t happen in this case because each of the individual 142 commands takes less time (showing and hiding the progress window 142 times would be more confusing and distracting). Sorry, the only long-term way to solve this would be to eliminate the factors that cause the delay (i.e. speed up the connection or run gdb locally).
Thanks for the update. Most likely this is caused by an incompatibility between the libusb library used by OpenOCD and a specific USB host controller, or a specific driver version. The best workaround would be to try using the Segger J-Link firmware for ST-Link. J-Link uses its own driver and its own gdb stub, so it should not trigger any bugs that are specific to OpenOCD.
Hi,
It looks like the OpenOCD is not able to find the ST-Link instance (no device with a VID of 0x0483 is listed). Please double-check that you can see the ST-Link in Device Manager and that it’s not hijacked by VMWare or USB-over-Network software that would hide it from the regular programs like OpenOCD.
Hi,
As most of the slowdown comes from the gdb debugger itself, we won’t be able to fully eliminate it, however we could try reducing it. Specifically, VisualGDB will detect when VS tries to disable all nested breakpoints (-break-disable 4.1, -break-disable 4.2, …) and will instead proactively disable all of them in one command after the first few ‘disable’ requests (-break-disable 4.1 4.2 4.3 …). You can gauge the performance improvement from this fix by running the large -break-disable command manually.
Another option would be to try running a Windows build of gdb (i.e. from a cross-compiler). This could significantly reduce the command latency and hence reduce the overall slowdown.
Looks like you have not replaced the version of the path with the forward slashes.
Please also replace C:/Users/Avi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32 with $(BSP_ROOT).
Thanks for the clarification, it explained what is going on.
It looks like you have created the project using the “Clone STM32CubeMX sample” option and not using one of the regular VisualGDB project templates.
The cloned STM32CubeMX projects do not use the regular system of VisualGDB’s embedded frameworks and hence will only work with a specific version of the STM32 BSP. We normally advise using them to quickly explore the STM32 examples, and then create a regular project using one of the normal samples. We will try to update our documentation to make this more clear.
Either way, we have updated the logic for generating the projects so that the absolute paths won’t get hardcoded for new projects (even when cloning the STM32Cube project samples) in this build: VisualGDB-5.4.105.3127.msi
In order to fix a project that was created earlier, please try opening the .vcxproj file in a text editor and replace all instances of C:/Users/Avi/Documents/G3/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32 with $(BSP_ROOT). Please also search the .vcxproj file for “c:” to ensure that no other absolute paths are hardcoded.
Thanks for the update. It looks like the STM32 BSP might be missing or incomplete on the second machine.
Have you tried creating a new project for the same device on your second machine using the VisualGDB Project Wizard, as we suggested earlier?
If this didn’t help, the STM32 BSP on the machine might be corrupt/incomplete. Please try removing it via Tools->VisualGDB->Manage VisualGDB Packages and then try creating another STM32H7 project from scratch. Please ensure that the download and installation of the BSP completes without any errors and you should be able to use build STM32-based projects on that machine.
The external dependencies are computed by Visual Studio automatically and may take some time to be refreshed, or may not load until you open some files in an editor. The easiest way to check that the new project is operational is to try building and debugging it. If it doesn’t work, please share the error message(s) you get and we will help you resolve them.
