[support]

Hi,

This looks like an incompatibility between OpenOCD and your USB driver. Please try replacing the OpenOCD executable in %LOCALAPPDATA% with this one: http://sysprogs.com/files/tmp/openocd.exe

If it doesn’t work, please share an updated OpenOCD output.

 

 

[support]

No problem. It looks like we will need to know more details about your setup (specific installation IDs) and may need you to run our internal diagnostic tool in order to see what is going on. Please create a support ticket here and we will get back to you with details.

[support]

No problem. Just a heads up that you may still qualify for a 50% renewal discount (that will add 1 year to the previous expiration date even if it’s in the past or in the future), Simply use this page to get an automatic renewal quote.

[support]

Hi,

This might have something to do with the debug symbol settings. Please follow this tutorial for a detailed explanation of symbol-related settings and troubleshooting tips. If you have any further questions, please let us know more details  per tutorial and we will help you understand what is going on.

[support]

Hi,

Please ensure you are using MSBuild-based projects, not GNU Make-based ones. The “Excluded from build” flag is only supported when using MSBuild.

If you specifically need to use Make, please consider patching the Makefile instead (conditionally removing specific files from all_source_files using the $(filter-out …) syntax) or adding an #ifdef directive inside the file itself.

[support]

No problem, we can walk you through the necessary setup. Please let us know the email associated with your license key (or update your forum profile to match it) and we will be happy to share the detailed instructions.

[support]

You are welcome. If you encounter further issues, don’t hesitate to create another thread.

[support]

Sorry for the inconvenience. The error is not related to the VS version and happens when the session key downloaded from the VisualGDB server is not valid. It is hard to say what could be interfering with the key loading mechanism without knowing the specifics of your setup, so the best way to diagnose this would be to compare this machine with another one where VisualGDB works and try eliminating the differences one-by-one.

[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.

[Author]

Posts