[support]

The second last line can be ignored. It just means that VisualGDB closed the connection without issuing the proper shutdown command and it shouldn’t matter for connection tests.

This time it actually looked like a successful test, so you should be able to debug your project now, although all we changed in that build was adding extra logging, so the problem might reoccur later.

[support]

Thanks for the update. We have updated the temporary build to include more logging. Please try this one (same link):  http://sysprogs.com/files/tmp/openocd.exe

[support]

Sorry, not sure what your question was. If you could provide an example of what you are trying to achieve, we should be able to help you find the correct setting.

[support]

Thanks for the detailed description. Since this could be caused by a specific version of Boost, could you please share an archive with your MinGW toolchain (including the boost version you are using)?

You can upload the archive to any file sharing service (e.g. Dropbox) and either share a link here, or report it via our support form.

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

[Author]

Posts