[support]

Hi,

OK, we’ve tried reproducing this with the following extra line in Makefile:

ifeq ($(TARGETTYPE),APP)
$(BINARYDIR)/$(TARGETNAME): $(all_objs) $(EXTERNAL_LIBS)
    $(LD) -o $@ $(LDFLAGS) $(START_GROUP) $(all_objs) $(LIBRARY_LDFLAGS) $(END_GROUP)
    @echo "LEDBlink.cpp", line 10 : warning : #177-D: function "naughty_function"  was declared but never referenced
endif

The vgdbsettings file contains the following element:

  <BuildMessageTemplateFile>BuildMessageRegexes.xml</BuildMessageTemplateFile>

The BuildMessageRegexes.xml defines GCCMessage as follows:

  <GCCMessage>"(.*)", line ([0-9]+) : (error|warning) : (.*)$</GCCMessage>

This does actually produce the expected results (the message is converted to VS format in the Build Output window and VS recognizes it):

1>e:\projects\temp\EmbeddedProject19\LEDBlink.cpp(10): warning : #177-D: function "naughty_function"  was declared but never referenced

Please try checking your code against the examples shown here (note that this forum engine converts the ” character to a slightly different one and it won’t work if you simply copy-paste it). If it does not work, please try reducing the problem to a GCC project with an ‘echo’ line injected into the Makefile and send us the entire repro project so that we could help you troubleshoot this.

[support]

Hi,

The solution you have found should work. You can also override the _estack symbol name by editing the .vgdbsettings file (search for the ‘EndOfStackSymbol’ element).

[support]

Hi,

Looks like the Clang IntelliSense might be having troubles locating some header files. Are you using a Makefile-based project or an MSBuild-based one?

Does changing the MCU forth and back (so that VisualGDB regenerates all settings) resolve this?

[support]

Hi,

It’s hard to say what could be causing this without seeing further details. One cause could be the header directories. Regenerating the project settings (e.g. by changing the MCU forth and back) could resolve this.

If it does not help, please let us know the exact details of the errors you are getting and we will help you.

[support]

Hi,

Our UART tutorial is indeed old and covers the older STM32 StdPeriph library. We will eventually add another version of it showing how to use the newer HAL library, but currently our best advice would be to look up the UART example for your board (select “use examples from STM32Cube” on the sample selection page of VisualGDB Project Wizard) and use the code from it.

[support]

Hi,

Thanks for reporting this, looks like the updated BuildMessageRegexes.xml file contained a small error. We have updated the version linked from our tutorial. Let us know if it works.

[support]

Hi,

This error happens when VisualGDB tries to move the generated binary from the .data section to .rodata. Looks like the ESP32 objcopy tool has troubles parsing the ESP32 ELF files.

Similarly to the previous step, please try locating the .data2rodata.rsp file and experiment with the command line to find a setting that works.

[support]

Hi,

This sometimes happens when the target system has loops in symbolic links (e.g. /usr/include/subdir linked back to /usr/include, resulting in an infinite /usr/include/subdir/subdir/subdir/… loop). In most of the cases those errors can be safely ignored.

[support]

Hi,

You can try adding a new cross-compiler-based Linux configuration to an existing project as shown in this tutorial: https://visualgdb.com/tutorials/porting/linux/

[support]

Hi,

Please try selecting “reinstall” in the VisualGDB installer or simply uninstall VisualGDB and install it back. This should fix the integration issues.

[support]

Hi,

No problem, we help you pinpoint this and find a workaround. Could you please attach a screenshot of the IntelliSense errors you are getting so that we could check if they look like any of the known issues?

[support]

Hi,

We have been investigating this since the slow extension reporting was added in one of the VS preview builds and it looks like t might be caused by the “Start your trial” message shown by VisualGDB when you start VS. We will look into displaying the window when a VisualGDB project is opened instead.

If you believe something else is affecting the startup time, please check the View->Other Windows->VisualGDB Diagnostics Console window. The first line there should report the actual time it took VisualGDB to initialize.

[support]

Hi,

We have successfully run our internal integration tests on VS2017 and have also received feedback from our users indicating that the main functionality works. There are minor glitches (like VS showing the “VS2015” label for the old projects), but they don’t disrupt the workflow.

[support]

Hi,

OK, this means that the esp32 linker cannot convert the binary file to an ELF file (so that the linker could merge it into your project). Please try locating the <file>.bin2obj.rsp file in your build folder and running the xtensa-esp32-elf-ld.exe manually with the flags specified there. Then try experimenting with adding and removing flags to see if ESP32 requires some special options to make it work.

Once you get a combination of options that work, you can edit the %VISUALGDB_DIR%\MSBuild\Targets\binary.targets file to ensure VisualGDB always uses those options.

[support]

Hi,

It’s hard to say why the breakpoints would not work. ESP32 and ESP8266 is generally very unreliable and some other settings may be interfering with the breakpoints. Our best advice would be to try setting them in different locations and try to see what causes them to fail (e.g. code in RAM/FLASH or code executed during startup).

[Author]

Posts