Forum Replies Created
-
Posts
-
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.
It looks like Visual Studio runs out of memory somewhere inside the logic responsible for handling the editor markers. If we encounter this behavior during our internal tests, we should be able to fix it. Please also consider filing a bug report with Microsoft, as it looks like the problem might be on their side (the exception stack does not contain any VisualGDB-related frames).
Thanks for clarifying this, it indeed looks like we missed this scenario.
The logic for quickly checking whether a certain project is a VisualGDB-based one is designed to run as quickly as possible without loading any advanced objects, so it isn’t able to do any advanced checks like following the toolchain names. However, we can check for other markers (e.g. references to .vgdbsettings files) that would be present in the file.
Would you be able to send us your .vcxproj file so that we could check for the best way to update our first-stage loader?
Hi,
It does look like some sort of a low-level communication issue between OpenOCD and the JTAG probe. If others have reproduced the same problem outside VisualGDB, it may indicate that the Espressif’s OpenOCD port is simply not compatible with this version of J-Link.
Our best advice would be to try one of the debug probes that is fully supported (e.g. Olimex ARM-USB-OCD-H or any other one based on the FT2232 chip). Also if Espressif fixes the issue in the future in their github repository, please feel to let us know and we will be happy to release an updated binary package with the fix.
Hi,
As of v5.4, most of the windows should automatically pick up the regular VS fonts and colors. If it doesn’t happen, please try attaching the screenshots of both the VisualGDB’s window and a normal VS window having a different font size and we will look into this.
No problem, we have added a registry setting that fully restores the old behavior for all of the projects on a specific user account.
Please try this build: VisualGDB-5.4.105.3118.msi
Then, set the HKEY_CURRENT_USER\Software\Sysprogs\VisualGDB\Settings\BSPFlagsOverridePerConfigurationFlags value in registry (REG_DWORD) to 1, or simply use the attached .reg file.
Please note that both the original change and this fix only affect the logic for generating the mcu.props file, that happens each time you change a setting on the first page of VisualGDB Project Properties and click “Apply”. Hence in order to restore the old behavior, please edit any setting on that page after updating the registry. You can verify that the mcu.props overrides the settings from the .vcxproj file by checking the “Condition” attribute, e.g.:
<ClCompile> <Optimization Condition="true">O3</Optimization> </ClCompile>
The projects that were created with the old VisualGDB version and were never edited with v5.4 do not need to be updated as their mcu.props file still uses the old syntax.
Let us know if you have any further questions/suggestions and we will be happy to help.
Sorry about that. There is no need to roll back – we can add a setting to VisualGDB that will allow switching between the old and the new behavior, although the redundancy between the optimization setting in the VS properties and the manually specified flag in the stand-alone project properties may cause further disturbances in the future.
We can also create a small tool that will check the stand-alone projects for the optimization flag and would move it to the correct VS-level property, eliminating the redundancy. Depending on how your projects are structured, running a single tool followed by a command-line build could be viable. If not, we can add the setting described above.
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.
The VisualGDB variables work on top of CMake, hence they are not mapped back to it. Otherwise, the project would need to be rebuilt each time you select a different target to debug.
If you could let us know what you are trying to accomplish, we could try to suggest a workaround.
Thanks for the description. Looks like some of the changes you made to the project are indeed preventing VisualGDB from being loaded. The latest VisualGDB 5.4 uses a 2-stage mechanism to load itself. First, it starts a very lightweight project loader that checks the opened .vcxproj files for the $(VISUALGDB_DIR) or <Platform>VisualGDB</Platform> text. If not, it assumes the project is not VisualGDB-based and skips loading the rest of VisualGDB. This eliminates any delays when loading non-VisualGDB projects (fully initializing all VisualGDB components does take a few seconds).
VisualGDB projects created via the wizard should contain one of those strings, however if you have manually removed them, indeed the 1-st stage loader will consider this project to be a non-VisualGDB one and will not load the main part of the plugin. Please double-check the .vcxproj file for the strings mentioned above. If they are not present, please try comparing the file to a newly created .vcxproj file and adjust it accordingly.
Let us know if you need further details and we will be happy to help.
Sorry, this is actually by design. The settings in VisualGDB Project Properties are shared between all CMake targets, while the command-line arguments normally make sense only for a specific targets.
Hence VisualGDB would normally expect you to specify the arguments via the VS Project Properties for each target (i.e. item with the console icon in the Solution Explorer) separately and will automatically substitute them to the $(SelectedCMakeTargetArgs) variable based on the currently selected startup target. This eliminates the need to change the arguments when debugging another target in a multi-target project.
Hi,
Sorry, this is not supported directly yet, although it is one of the top priority features scheduled for v5.5. Please expect a preview build with this feature around late Spring/early Summer.
Hi,
No problem, we can help you resolve this.
Adding a Windows configuration to a regular Win32 project is a part of our automated pre-release tests (we have also rechecked it manually now just in case), so the issue is likely caused by some specific setting in your project. If you could share either the project that triggers this, or compare with with a freshly created one and narrow down a specific setting, we should be able to release a hotfix promptly.
