[support]

Thanks for renewing your support. We have investigated and fixed the problem with the std::vector arguments in this build: VisualGDB-5.4.103.2881.msi

The IntelliSense Engine setting works as described below:

• The “default” option will choose the current global default (shown in brackets). You can change it via the Clang IntelliSense Diagnostics Console.
• The “Regular VC++ IntelliSense” option will choose the VC++ IntelliSense regardless of the global default
• The “Advanced Clang IntelliSense” option will choose Clang IntelliSense regardless of the global default

[support]

Thanks for reporting this. The warning is indeed triggered by the syntax used in the VisualGDB’s Makefile. Please try changing the rules near the $(LINKER_SCRIPT) check as shown below:

EXTRA_DEPENDENCIES :=

ifneq ($(LINKER_SCRIPT),)
EXTRA_DEPENDENCIES += $(LINKER_SCRIPT)
endif

ifeq ($(TARGETTYPE),APP)
$(BINARYDIR)/$(TARGETNAME): $(all_objs) $(EXTERNAL_LIBS) $(EXTRA_DEPENDENCIES)
	$(LD) -o $@ $(LDFLAGS) $(START_GROUP) $(all_objs) $(LIBRARY_LDFLAGS) $(END_GROUP)
endif

ifeq ($(TARGETTYPE),SHARED)
$(BINARYDIR)/$(TARGETNAME): $(all_objs) $(EXTERNAL_LIBS) $(EXTRA_DEPENDENCIES)
	$(LD) -shared -o $@ $(LDFLAGS) $(START_GROUP) $(all_objs) $(LIBRARY_LDFLAGS) $(END_GROUP)
endif
	
ifeq ($(TARGETTYPE),STATIC)
$(BINARYDIR)/$(TARGETNAME): $(all_objs) $(EXTRA_DEPENDENCIES)
	$(AR) -r $@ $^
endif

If this triggers errors, please double-check that the ‘tab’ symbol before the $(LD) and $(AR) commands got copied correctly.

We have also updated VisualGDB internally so that it will now use the new rule syntax for new projects that won’t trigger any warnings.

[support]

Thanks for clarifying this. It might be caused by an incomplete or corrupt VS installation. Please try repairing the VS installation and check if you can create regular VC++ projects.

If this doesn’t help, please try running Visual Studio with the /log parameter as described here and check the activity log for messages related to VisualGDB.

[support]

Hi,

Thanks for updating your forum email. This looks like a known bug in the master branch of the ESP-IDF. When building with CMake on Windows, it tries running the Python script directly instead of using the toolchain’s python executable. As a result, the script doesn’t work properly.

You can reproduce this outside VisualGDB by building the project with idf.py (wrapper for CMake/Ninja build).

The easiest workaround would be to use GNU Make instead of CMake for affected projects until Espressif fixes the issue.

[support]

Hi,

Sorry about that. If you could share more details about the crash (whether VS itself or the Clang IntelliSense engine crashes, what is the call stack of the crash or any associated error messages) we should be able to suggest a workaround or provide a fix.

[support]

Hi,

It looks like the floating license data has not been loaded properly. Please try restarting Visual Studio and check the Help->About VisualGDB window again.

Please also ensure that your antivirus is not blocking SessionServer.exe – the process responsible for sharing the floating session keys between multiple VisualGDB instances on the same machine. We had a similar issue reported by another user and it turned out their antivirus was silently preventing VisualGDB from reading the shared memory block from SessionServer, so it didn’t trigger any error immediately, but the loaded keys were zeroed, causing a NullReferenceException.

[support]

Hi,

Unfortunately this is not possible, as the regular VC++ IntelliSense is closely tied to the regular VC++ project engine and hence will not work with the Advanced CMake engine that is completely different.

That said, if you could share the exact repro steps of the problem you mentioned and we could reproduce it on our side, we should be able to understand why does Clang IntelliSense get slow and either fix it, or suggest a setting (e.g. IntelliSense-only precompiled header) that will radically improve the performance.

[support]

Hi,

First of all, thanks for reporting the broken link for the kgdboe download.

Second of all, KGDBoE will likely not work with Raspberry Pi (or may work very unreliably). Please try using a JTAG debugger instead as described in this tutorial.

We have also updated the documentation page for the supported debug methods to reflect the advantages and limitations of various debug methods. Hope this explains. Let us know if you have any further questions.

[support]

Good to know it works. If you encounter further issues, don’t hesitate to get back to us.

[support]

Hi,

This does look like a bug. We should be able to fix it, however it look like your support period has expired. Please renew your key here and we will investigate and fix this issue.

[support]

Hi,

Looks like your support period has expired. Please renew your key here or let us know the updated email if you have purchased a different one and we will help you resolve this.

[support]

Hi,

Please try using the VisualKernel Project Properties -> Module Build Settings -> Kernel Symbols for Debugging setting. It will allow caching the symbols/sources for the new kernel and using them for debugging the module.

[support]

Hi,

v3.2 and master are different branches of the ESP-IDF repository maintained by Espressif. Please contact Espressif for details on differences between specific branches.

VisualGDB is designed to work with any branch of the ESP-IDF framework as long as it can be built using command line, hence it does not require any porting on our side. Our toolchains indeed include pre-downloaded releases of the ESP-IDF framework, however they come straight from the Espressif’s github repository and are not modified by us in any way.

[support]

Perhaps some of the native ESP8266 tools also only work on 64-bit targets? Please try building the failing project manually from the Arduino IDE. Does it build successfully?

If yes, please try comparing the Arduino-builder command lines from VisualGDB and the Arduino IDE (you can use Process Monitor to find out the command line used by the Arduino IDE). Let us know if you notice any differences and we will help you configure VisualGDB to work around them.

[support]

Hi,

Based on a quick look, it looks like someone ported the MSP430 gdbproxy to work with AVR devices. However, based on the project stats (0 issues, 0 releases, 4 commits), it is likely in the proof-of-concept stage and may not work reliably at all.

If you would like to try it out with VisualGDB, you can build it and use the “Custom GDB Stub” setting in VisualGDB debugging properties, however if you are not prepared to troubleshoot the problems of the gdbproxy itself, we would not advise doing that and we would recommend using the more popular AVaRICE tool (included in our AVR toolchain).

[Author]

Posts