Forum Replies Created
-
Posts
-
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.
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.
