[support]

Hi,

Normally you can select the device in VisualGDB Project Properties -> Debug settings. Then VisualGDB will remember it and pass it to the Segger tool so it won’t ask it each time.

Let us know if this does not work.

[support]

Hi,

Thanks for reporting this, looks like the nRF51 port of mbed expects you to program the softdevice separately. We have published a detailed tutorial showing how to edit the linker script to embed the softdevice in your project just like VisualGDB does normally: http://visualgdb.com/tutorials/arm/mbed/nrf51/

As for nRF52, we will happily support it once mbed officially supports it. If there is an unofficial port already, you can run our open-source mbed BSP generator on it and import the resulting BSP into VisualGDB.

[support]

Hi,

OK, please try the latest VisualGDB 5.1 Preview 2. You can tell it that a type A is an alias for type B by adding a .natvis file to your project with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
  <Type Name="std::vector&lt;int&gt;">
    <AlternativeType Name="IntVector"/>
  </Type>
</AutoVisualizer>

Note that the Type element should not contain any elements other than AlternativeType, otherwise instead of using the normal STL visualizers VisualGDB will actually follow the Natvis rules defined in the .natvis file.

[support]

Hi,

OK, folks, we have added mbed support to VisualGDB.

Please try the newest 5.1 Preview 2.

A detailed tutorial is here: http://visualgdb.com/tutorials/arm/mbed/

[support]

Hi,

Perhaps some of the data gets overwritten? Please try setting a breakpoint right after initializing them with zero and use the Watch window to check whether they actually contain zeros. If not, check that those variables actually fit in the RAM area of your device. If yes, try setting a data breakpoint on one of them to see what code modifies it.

[support]

Hi,

Not sure what do you mean by the constructor library, but we actually have a tutorial showing how to access Raspberry Pi camera from your VisualGDB projects: http://visualgdb.com/tutorials/raspberry/camera/

And another one with OpenCV: http://visualgdb.com/tutorials/raspberry/opencv/camera/

Consider following those to get basic understanding of using external libraries with VisualGDB.

[support]

Hi,

Thanks for reporting this, we have fixed it in the upcoming Preview 2.

[support]

According to this thread, it looks like this is no longer possible in VS2015. Consider leaving feedback there so the VS guys could consider fixing this.

[support]

Hi,

Most likely the passphrase did not get removed properly or the libssh2 library that VisualGDB is using fails to recognize it.

We recommend checking the “setup public key automatically” button to let VisualGDB generate a private key, store it in a Windows key container (automatically protected by your Windows account password) and use it automatically.

[support]

Hi,

You can diagnose this by adding a new function to your library (e.g. testfunc()), calling it from your code and then checking whether the library on Raspberry Pi contains the new function by running the following command:

nm <library path> | grep <function name>

You can find out the path of the library loaded into your application by running the “info shared” command in the GDB Session window.

[support]

Hi,

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.1.2.628.msi

 

[support]

Hi,

Did you get any toolchain testing errors while creating your project? Normally IntelliSense is configured based on the results of a toolchain test.

[support]

Hi,

We expect a preview build this week. We are going to support the latest version from github.

[support]

Hi,

Here’s an example of modifying the Makefile to copy your .so file in the ..\AllLibraries directory (it assumes that you are building on Windows with a cross-compiler):

../AllLibraries:
    mkdir ..\AllLibraries

ifeq ($(TARGETTYPE),SHARED)
$(BINARYDIR)/$(TARGETNAME): $(all_objs) $(EXTERNAL_LIBS) ../AllLibraries
    $(LD) -shared -o $@ $(LDFLAGS) $(START_GROUP) $(all_objs) $(LIBRARY_LDFLAGS) $(END_GROUP)
    copy /y $(subst /,\,$@) ..\AllLibraries\$(notdir $@)
endif

VisualGDB does not overwrite the Makefile, it carefully adjusts parts of it (e.g. the SOURCEFILES assignment line and the lines below the #VisualGDB: GeneratedRules marker).

Normally VisualGDB should add the -Wl,–rpath=’$$ORIGIN’ flag to linker flags and that should add an attribute to the linked file telling the library loader to check the directory of the executable for missing library dependencies. Do you see this flag in your build log?

[support]

Hi,

Thanks for the log files. It looks like Qt Creator is using Python extensions to extract meaningful values from the STL variables. VisualGDB does the type matching on the Visual Studio side in order to support gdb builds without Python support. As a side effect of it, it cannot automatically resolve typedefs without issuing further commands.

The upcoming VisualGDB 5.1 supports Natvis, so we could add an extension to its format in order to explicitly specify typedefed types and map them to STL containers. Would that be a reasonable option?

[Author]

Posts