Forum Replies Created
-
Posts
-
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.
No problem. We have reviewed the tutorial and updated it to reflect the automatic toolchain lookup and installation supported by VisualGDB 5.4.
Please have a look through the updated tutorial and let us know if you have any questions: https://visualgdb.com/tutorials/arm/multiuser/
If you encounter further problems, please use the 3-step format to describe the issue so that we could suggest the best way to fix it.
Hi,
Sorry, due to the timing constraints, we have to charge an hourly fee for the screen sharing sessions (please contact our sales if you would like to schedule it), however we are happy to help you either here or via the support form (in case you don’t want to share your setup details publicly).
We also have a detailed tutorial about manually sharing the BSPs between multiple users here: https://visualgdb.com/tutorials/arm/multiuser/
No problem, we can help you with this, however we would need to know more about your setup.
Please let us know your project type (Embedded/Linux/MinGW/Android/Arduino/ESP32), where is it built (remote machine, local cross-toolchain), the toolchain you are using and the exact errors you encounter and we will walk you through the necessary setup.
Sorry, we can only provide help to users with active technical support. If anyone else would like to share their workaround to a similar problem here, they are more than welcome to do so, however we will not be able to provide any further help with this until your license is renewed.
Hi,
Unfortunately this is a design limitation of Visual Studio itself. It does query the breakpoint status from the main thread, so if your gdb communication is slow and setting a breakpoint results in 142 different sub-breakpoints, each of them taking considerable time, the delays will add up and the GUI will be frozen until all of those commands complete.
As a workaround, please try running gdb locally using a gdbserver. This will greatly reduce the command latency.
We can also suggest a few other tricks to make VisualGDB regroup some of the commands, however we would need to verify your support status first. Hence please let us know the email address associated with your license key, or update your forum profile to match it.
Hi,
The easiest way to download the necessary toolchains would be to try creating another project of the same type on the new machine. The VisualGDB project wizard will then automatically download the necessary packages.
You can also configure VisualGDB to automatically deploy certain versions of toolchains, BSPs and debug packages to all machines in your organization using Team Settings as shown in this tutorial.
Let us know if you have any further questions and we will be happy to help.
Most likely something about a specific file is triggering a memory leak somewhere inside Visual Studio. As the error occurs outside the VisualGDB codebase, it is hard for us to pinpoint the root cause of this.
The best advice we could give is to try splitting the source file that typically triggers this into multiple smaller files. This will reduce the amount of information Visual Studio has to process and might prevent the problem from happening.
