Forum Replies Created
-
Posts
-
Strange. Please double-check that the <VisualGDB>\Arduino\arduino-builder.exe file has a size of 12186624 bytes.
Please also try rebuilding the project and check that the call to gdbstub_do_break() from gdbstub_init() in gdbstub.c is not grayed out:
Hi,
Sorry ESP-IDF 4.1 is not a stable release yet and hence is not supported by VisualGDB.
That said, ESP-IDF 4.0 had a similar issue and we fixed it in the following build: VisualGDB-5.5.1.3274.msi. Please feel free to try it as it may resolve the v4.1 issues as well.
No problem and thanks for the detailed description. It helped us pinpoint and fix the issue so that the GDBSTUB_BREAK_ON_INIT will now work as expected.
Sorry for the false alarm, from the description we had, the problem looked like a missing flag somewhere in the settings and it was not possible for us to verify it without a screenshot (the call to gdbstub_init() would be highlighted differently based on the effective configuration). It turned out, the flag was specified, but then got lost inside the Arduino build logic.
Please try this build, it will work out-of-the-box: VisualGDB-5.5.1.3274.msi
Hi,
For MSBuild-based projects you can set the C++ language standard via VS Project Properties (not VisualGDB Project Properties) -> C/C++ -> Advanced -> Language Standard for C++ files (that will set the CPPLanguageStandard value in the .vcxproj file). If you believe this causes an error, please identify whether it affects building or only IntelliSense and whether you are using Clang IntelliSense or the regular VC++ IntelliSense.
If the project cannot be built, your compiler may not support C++17. If the problem is specific to IntelliSense only, please try reproducing it on a clean project and let us know the exact repro steps (see the 3-step format here).
Regarding the CMake projects, please try using the new Advanced CMake Project Subsystem. It automatically keeps the IntelliSense settings synchronized with the actual build settings, eliminating the need for any manual setup. If you would like to use the old CMake project system (based on VC++ projects), you would need to manually add the “–std=” option to VisualGDB Project Properties -> IntelliSense -> Additional flags for C++ files.
No problem, please share the screenshot of the Visual Studio window with the main sketch file open, the screenshot of the first page of VisualGDB Project Properties, the screenshots of SmarTTY window showing the output from the board at baud rates of 57600, 74880 and 115200 and we will help you understand what is going on and find the working settings.
Please follow our gdb stub debugging tutorial. It provides a very detailed explanation of all necessary configuration steps: https://visualgdb.com/tutorials/arduino/esp8266/
VisualMicro might be using a different debug mechanism that patches the code at compile-time to handle breakpoints and variable output, that is less flexible than the fully fledged gdb-based debugging, but would not rely on the Espressif’s GDB stub.
Please check what debug method the other tool is using (e.g. gdb stub, JTAG or the compile-time breakpoints) and ensure you are using the same settings with VisualGDB.
Also please do actually try different baud rates (especially 57600, 74880, 115200). The $T05#b9 message might be displayed under a different baud rate than the welcome banner and hence would not be properly visible.
If the $T05#b9 message is not shown despite trying different baud rates, the board you are using may not be supported by the gdb stub. Please contact Espressif for further details.
Hi,
Thanks for reaching out to us. Most likely, the debug probe internally exposes several USB interfaces (that technically count as separate USB devices) without reporting a unique serial number and that confuses the VisualGDB logic.
Please try locating the device in the Windows Device Manager (the debugger endpoint, not the virtual COM port and check its full hardware ID with VID, PID and MI strings). Then try editing the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\QuickSetup\interfaces.xml file to specify the UsbIdentity\Interface element that matches the MI value from the hardware ID.
Then please restart Visual Studio and see if the problem is resolved. If yes, please let us know the changes you made to interfaces.xml and we will update the version shipped with VisualGDB.
On a side note, using the CMSIS-DAP interface for debugging usually results in incredibly slow debugging performance (every single step can take about 5 seconds) due to the USB latency arising from the use of the USB HID class. If you have a feedback channel to the engineering team behind this Analog board, please consider suggesting that they update the firmware to expose an additional USB BULK interface and submit an OpenOCD patch to recognize it. It would require installing the WinUSB driver (as with many other debug probes), but would make debugging more than 10x faster.
Most likely, the gdb stub baud rate is configured incorrectly.
Please try opening the COM port with SmarTTY and resetting the board. The gdb stub should output the following text (indicating that it’s ready for gdb to attach):
$T05#b9
If you see anything different, please try using different baud rates to see if any of them works. Please also ensure you have followed all other steps from our ESP8266 Arduino tutorial.
Hi,
Please try creating an empty file at the path shown in the error message. Alternatively, please try using the following tool to uninstall VisualGDB: https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
Thanks for the detailed repro steps. It turns out, a recent change to the Arduino ESP8266 package indeed broke FLASH programming for some targets.
We have added a workaround for this to the following build: VisualGDB-5.5.1.3273.msi
Please share the exact steps to reproduce the problem from the very beginning (i.e. what exactly to specify on each page of the wizard while creating the project, what exact command to use in order to trigger the problem).
Hi,
Normally, VisualGDB would launch the Arduino builder that dumps various variables, letting VisualGDB reconstruct the command line. Unfortunately, it is not possible to change it explicitly, however in most of the cases, it should be derived correctly.
Please try checking via Tools->VisualGDB->Manage VisualGDB Packages whether you have multiple versions of the Arduino package installed. If this is the case, please try removing the old package versions. If it still doesn’t help, please let us know and we will investigate this further.
Sorry, if the 2 projects behave differently, something either about the project structure, or about the project settings is responsible for the difference.
Normally, the line should cause a special type of exception that would be intercepted by VisualGDB’s semihosting logic, however if it doesn’t happen, something interferes with the exception reporting mechanism, preventing VisualGDB from recognizing it.
The best way to diagnose this type or errors would be to start with a working project and slowly change it one step at a time until it is 100% equivalent to the broken one (i.e. uses the same sources, produces a comparable output, etc). If at this point the 2 projects still behave differently, simply use the new project file instead of the old one (although checking it into source control over the old one will likely reveal some differences).
