Forum Replies Created
-
Posts
-
OK, thanks for confirming this. We have rechecked everything again and confirmed the problem.
Turns out, the issue was caused by a recent update on our server that was not yet caught by our integration tests (we run the full set of tests before each preview release, such as v5.5 Preview 5). The daily infrastructure tests run on the latest VS2019 and hence didn’t catch this either.
Sorry for being skeptical about it – we had previously encountered very similar errors caused by client-side antivirus software trying to hijack SSL connections without properly installing new root certificates, and another case where it was caused by broken group policy, so it looked like another instance of that problem. Either way, we have fixed the issue on our server and also updated the infrastructure tests to check for it, so it shouldn’t happen again.
Hi,
Sorry, we don’t have a tutorial on merging multiple projects. Our best advice would be to look through our documentation on project types to understand the type of the project you are using, and where it stores the lists of files and settings.
Then, you can try editing these locations manually to merge the settings from different sources.
If you could let us know the type of the project (per the documentation page), we can share a few pointers, but this will still require non-trivial editing of configuration files, and many need some troubleshooting.
Sorry, we have a large set of integration tests that is run on 32-bit and 64-bit Windows 7 and Windows 10 using VS2008, 2010, 2012, 2013, 2015, 2017 and 2019, and they do not trigger the issue.
It looks like something is broken with a specific laptop, so our best advice would be to reinstall Windows there.
Sorry, we are not sure what you meant. If you are looking for a specific feature, please consider searching our tutorials. They provide detailed step-by-step instructions for most of the features.
If you could still cannot find it, please attach a screenshot explaining what exactly you are looking for, and we will try to help you.
Sorry, we could not reproduce the stop with the Start target with the “run” command. Most likely, something on the gdb side is causing the stop. Please try examining the GDB output by switching the GDB Session window to All GDB Interaction mode.
Hi,
This might be caused by incomplete initialization of the floating license. First of all, please try the latest development build: VisualGDB-5.5.8.3742.msi
Then please try opening the Help->About VisualGDB window before you start the build. It will force the licensing logic to initialize and display an error message if there is any.
If nothing helps, please obtain a call stack of the MSBuild process as shown here and attach it here so that we could see what is going on.
Hi,
Indeed, the newer ESP-IDF versions use a different format for specifying some KConfig entries and VisualGDB 5.5 Preview 7 doesn’t parse it yet.
Please try this build: VisualGDB-5.5.8.3742.msi
No problem, we have added a checkbox to ignore the initial stop to the Debug Settings->Debug Mode view. Please try this build: VisualGDB-5.5.8.3742.msi
We also added support for deleting the stale entries from the symbol list by pressing the “Delete” key.
No problem, please try this build: VisualGDB-5.5.8.3740.msi. It will handle the symbols correctly when attaching.
You can disable the initial stop when attaching to processes by using the Debug->Attach to Process command. The dialog shown when pressing the “Find” button will display an option to suppress the initial stop.
Sorry, it’s hard to suggest anything specific, as the problem is happening on the network level and not on the VisualGDB level.
You can try reproducing the problem by creating a basic C# program with this code:
var str = new WebClient().DownloadString("https://visualgdb.com/hwsupport/catalog?version=latest");Also make sure that the VisualGDB proxy server settings are not set to something incorrect.
Sorry, looks like the file did not get attached properly. Do you mind packing it into a zip file and attaching it again?
It actually looks like your firewall or antivirus is preventing VisualGDB from downloading the latest package catalog. Please double-check your settings and make sure VisualGDB is allowed to access https://visualgdb.com/ and https://sysprogs.com/.
There are indeed a few commands and settings that would indeed result in using extra hardware breakpoints. The “info breakpoints” command together with the gdb session log should fully explain them though.
Hi,
This looks like some cached paths were not updated correctly. Please try reopening the Tools->VisualGDB->Manage VisualGDB Packages window and switch to the Online view.
You can also try deleting the %LOCALAPPDATA%\VisualGDB\PackageCatalog.xml file to make sure it definitely gets re-downloaded when switching to the Online view.
No problem, we can help you narrow it down. Please try following this tutorial to compare the build command lines used by VisualGDB vs. the Arduino IDE. You can also modify the command lines manually to see what exact parts of them triggers the different behavior.
Once you find a specific flag or option that causes the VisualGDB-based project to work differently, we can help you find the setting that allows changing it.
