[support]

Hi,

JAYLINK_ERR_DEV might indicate a driver issue. Are you able to use J-Link with OpenOCD (not Segger gdb stub) to debug normal ARM devices? If yes, it could be wiring problem instead.

[support]

Hi,

Thanks, we are aware of this. As those warning don’t really have any side effects and don’t appear unless the extra warnings are enabled, we recommend simply suppressing them via per-file settings.

If you don’t want to do that, you can send us the patch adding the necessary attributes and we will include it in our release branch, but we don’t have any plans of addressing them on our side, as we prioritize other features over it. Sorry.

[support]

Hi,

In order to keep VisualGDB price competitive, we only directly support the most popular devices and offer various customization mechanisms to allow our customers to easily add support for the devices that are not directly supported.

The easiest way to create a project for an unsupported device is to follow our legacy device tutorial.

Our BSP generators on github have a very basic Wiki page that outlines the basic concepts, but generating a full-blown BSP would much harder than just setting up a manual project (and exporting it to a template).

We also provide a service for creating BSPs for rare devices on demand, so if you don’t want to go through this process yourself, feel free to contact our sales to get a quote for a custom BSP.

[support]

Hi,

Sorry, that was Ctrl-Space, not Ctrl-Tab.

[support]

Hi,

Please try pressing ‘Ctrl-Tab’ while typing your code to activate IntelliSense popup explicitly. If it helps, please click the lightning icon at the bottom of the popup to enable the “show suggestions as you type” mode.

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

[Author]

Posts