[support]

Thanks for confirming your support status.

We have investigated the problem and confirmed that having multiple versions of the same Arduino tools installed may break some Arduino platforms despite VisualGDB specifically referencing the correct versions of the tools.

We have updated VisualGDB to detect the incompatible package versions and suggest automatically cleaning them up. Please try this build: VisualGDB-5.5.1.3282.msi

Once you open any source file of the Arduino project that doesn’t load due to conflicting packages, VisualGDB will show a yellow bar on top of the editor suggesting a cleanup of the packages. Please proceed with the cleanup and you will be able to build the project again.

[support]

Hi,

Most likely you are using a slightly older build of VisualGDB (the latest stable v5.4R12 build supports checking out the Arduino core). If you are using the R12, feel free to post the screenshot of the menu with the missing item and we will try to suggest the possible cause.

You can also clone the repository manually by running the following command in the “components” folder of your project:

git clone --recursive https://github.com/espressif/arduino-esp32.git arduino

This will have exactly the same effect as using the command from the menu.

[support]

Thanks for reporting this, it looks like a bug introduced by a recent refactoring in our development branch. Please try this build: VisualGDB-5.5.1.3277.msi

[support]

Thanks for clarifying this. It could be that the old toolchain you are using does not come with dummy syscall implementations that would not trigger the semihosting calls.

We could recommend 3 ways of solving it:

1. Run the program without debugging, reproduce the crash, attach to it and examine the call stack. You will likely see a call to printf() somewhere that triggered the semihosting call. Simply comment it out, or make it conditional in order to remove it.
2. Do not specify the –specs=nosys.specs at all and try building the project. Once it complains about missing _write() and other similar syscalls, provide your own implementations for them that will simply discard the data passed to them.
3. Try using our Advanced Semihosting and Profiler framework and select the option to ignore semihosting calls when the debugger is not attached.

[support]

Thanks for confirming your license key. Specifying –specs=nosys.specs manually should normally work.

If it doesn’t, please let us know:

1. What exactly you are trying to achieve? I.e. why simply not calling printf() is not an option?
2. What is the expected/observed behavior when you use the settings on the screenshot (e.g. expect the project to build, got a specific error)?

This should help us understand what is going on.

[support]

Hi,

It looks like you are using an old toolchain that doesn’t provide fine-grain control over semihosting calls. Please try unchecking the “Provide default stubs for system calls” checkbox (bottom of the 1st screenshot) and then either manually provide dummy syscall implementations, or manually specify “–specs=nosys.specs” via VS Project Properties (not VisualGDB Project Properties) -> Linker -> Command Line.

[support]

Hi,

Sorry, unfortunately the recent versions of STM32CubeMX are somewhat buggy and often include incorrect paths in the generated GPDSC files.

VisualGDB works around the known instances of this, but it looks like you have discovered another one. If you could reproduce it on a freshly created STM32CubeMX project and share it with us (along with the generated GPDSC file), we should be able to add a workaround rule.

If the problem is specific to a project that cannot be shared, please consider cloning our STM32CubeMX importing plugin from Github and adding logic similar to the ApplyFreeRTOSFixes() method that works around known STM32CubeMX bugs.

[support]

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:

Attachments:

You must be logged in to view attached files.

[support]

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.

[support]

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

[support]

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.

[support]

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.

[support]

Please follow our gdb stub debugging tutorial. It provides a very detailed explanation of all necessary configuration steps: https://visualgdb.com/tutorials/arduino/esp8266/

[support]

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.

 

[support]

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.

[Author]

Posts