Forum Replies Created
-
Posts
-
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.
Hi,
This looks like a Teensy-specific question rather than VisualGDB-specific one. Please consider asking on the Teensy forum instead.
Hi,
According to our records, your support period has expired. In order to continue receiving support, please renew your key here: https://sysprogs.com/splm/mykey
P.S. We do release toolchain updates regularly. However, if you decide to not renew your support and keep using an old unsupported version of VisualGDB, the new toolchains may indeed not work with it, as the internal changes to ESP-IDF often require updates on the VisualGDB side as well.
Hi,
It’s hard to say what exactly is going on here. From VisualGDB’s perspective, the gdb debugger works as expected, just never reports a stop anymore.
From GDB’s perspective, the gdbserver keeps reporting breakpoint events, but never reports any breakpoint being hit.
You can try using VisualGDB Project Properties to run the gdb debugger directly on the target (switch to custom mode and override the gdb command line). This will rule out any possible miscommunication between gdb and gdbserver.
If nothing helps, our best advice would be to try pinpointing a specific function that triggers the problem and try narrowing it down to a single executed line. E.g. some syscall, or some memory-intense operation could be triggering this.
Hi,
This looks like an ESP32 issue. Please refer to our ESP32 troubleshooting documentation for detailed instructions on resolving ESP32 errors.
