[support]

Hi,

This error means that the app_uart_init() function is declared, but not implemented in any source files included in your project. The easiest way to solve this type of problem is to quickly search for the function name (i.e. app_uart_init in the Nordic SDK installed by VisualGDB) that will point to the app_uart.c file.

You can then either include the file to your project manually (via Add->Existing Item) or enable the corresponding setting under VisualGDB Project Properties -> Embedded Frameworks to automatically include it as a part of the Nordic BSP.

[support]

Hi,

Please ensure you are using the Clang IntelliSense provided by VisualGDB that is specifically optimized to handle GCC-specific code.

If you are not sure, please attach a screenshot of the entire VS window showing the problem.

If switching the IntelliSense engine doesn’t help, please let us know your project type (Make, CMake, MSBuild, QMake, etc) and we will provide more detailed diagnostic instructions.

[support]

Hi,

Thanks for making the video. It indeed looks like the linker gets stuck and doesn’t exit even after you terminate it with Ctrl-C.

The linking is normally performed by your toolchain that is in turn invoked by CMake and unfortunately there’s not much VisualGDB can do about it. Please try building the project manually outside VisualGDB. If you observe different behavior, please let us know and we will help you narrow down the differences between the setup used by VisualGDB and the manual setup.

If the linking still gets stuck, please try using a different toolchain or experiment with the exact linker inputs in order to work around it (e.g. regroup the code into several static/dynamic libraries).

[support]

Hi,

Thanks for reporting this, it looks like we indeed missed this scenario (we tested with the Arduino Due, but not with Zero).

From the log file you attached, it looks like the upload COM port (used with the bossac tool) appears after Arduino Studio runs the 1200 bps sequence on the regular COM port selected for programming. Could you please confirm that via Device Manager? If this is the case, we can easily add support for this.

The warning might indeed indicate another bug. The Arduino builder tool expects the source folders to contain no other files, hence VisualGDB places the sketches and library files inside subfolders (instead of storing them in the project directory). Did you try adding a library residing directly in the project directory? If yes, please relocate it to a subfolder instead (please also confirm if this is the case, so we would add a more meaningful warning for this).

 

[support]

Hi,

Thanks for the detailed log. It looks like both valgrind components involved in debugging are started with matching settings, so the problem is likely caused by some settings on your Raspberry Pi interfering with valgrind. One quick way to fix this would be to reset the SD card image (we have just rechecked valgrind with the latest SD card image).

Another way would be to narrow this down by running the commands manually. I.e. restart Raspberry Pi to clean the /tmp folder and run the following commands manually:

mkdir /tmp/5a1490b2-2216-465a-a123-1534b7645f35
mkfifo /tmp/5a1490b2-2216-465a-a123-1534b7645f35/callgrind.out
mkfifo /tmp/5a1490b2-2216-465a-a123-1534b7645f35/valgrind.log
valgrind --log-file="/tmp/5a1490b2-2216-465a-a123-1534b7645f35/valgrind.log" --vgdb-prefix="/tmp/5a1490b2-2216-465a-a123-1534b7645f35" --tool=callgrind --callgrind-out-file="/tmp/5a1490b2-2216-465a-a123-1534b7645f35/callgrind.out" --vgdb=yes --vgdb-error=0 /tmp/raspTest2
vgdb --vgdb-prefix="/tmp/5a1490b2-2216-465a-a123-1534b7645f35" --port=2000

If the problem can be reproduced, please try experimenting with the prefix (e.g. locating it in a different directory or removing it completely).

If the problem does not reproduce, please try using the full command lines from the log (with the environment). If this causes the issue, try experimenting with the environment part to pinpoint a specific environment variable that breaks valgrind and remove it via Tools->VisualGDB->Manage SSH connections->Per-host settings.

[support]

Hi,

No problem and sorry for the inconvenience. We will consider making a specific check for this type of issue that will automatically suggest updating the necessary components.

[support]

Hi,

Sorry, it looks like an incompatibility between the different Preview builds. Please update VisualGDB to 5.4 Preview 4 and install the latest versions of the debug packages.

[support]

Hi,

Sorry, it doesn’t look like anything originating from VisualGDB. Please consider creating a discussion thread in CMake forums.

[support]

Hi,

The startup gdb commands are not transmitted via command line. Instead VisualGDB will send them to gdb that will in turn relay them to the segger gdb stub.

We would advise solving it in 2 steps:

• Understand what exact command line needs to be passed to the Segger J-Link gdb stub (refer to the Segger documentation or check with their support if you are not sure). Double-check that running it manually issues the correct reset signal.
• Enter the corresponding command in the “command line” field in VisualGDB Project Properties. If it doesn’t help, check via VisualGDB Diagnostics Console that VisualGDB is actually passing the correct argument.

[support]

Hi,

Thanks for sharing the output. It looks like VisualGDB doesn’t launch valgrind at all (or you did not attach the relevant part of the log).

Either way, please try this build, it will log more details about valgrind-related tools in the diagnostics console: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2395.msi

Please try reproducing the problem again and attach the entire contents of the VisualGDB Diagnostics Console so we could see what exactly is going on.

[support]

Hi,

Thanks for the feedback. We will try to rectify it in the upcoming Nordic SDK update.

As a workaround, please consider marking the files you don’t need as “Excluded from build”. Unlike the list of files, this flag won’t get overridden when you change settings/frameworks in VisualGDB Project Properties.

[support]

 

Hi,

It looks like it takes VisualGDB over 30 seconds to parse the source file. It could be expected first time you parse a file with many includes (Boost would be a perfect example of that), but then VisualGDB should cache the header file contents and the subsequent operations should be much faster.

Also the refactoring should normally show the “Searching for references” window while it analyzes the source. It is by design that this window blocks the reset of the Visual Studio GUI as editing the code while it is being analyzed would lead to unpredictable results.

The last log snippet looks like VisualGDB fails to properly display a popup hint for some part of the code. It should not cause any slowdown or any other issues and can be safely ignored. If it looks like VisualGDB consistently doesn’t show a popup for some code where it should work, please let us know the repro steps and we will investigate it.

[support]

Hi,

If you are using an MSBuild-based project, please use VS Project Properties->C/C++ to set the language standard directly.

If you are using Make, CMake or QMake, please use VisualGDB Project Properties -> Build Settings -> CXXFLAGS.

[support]

Hi,

Please try installing VisualGDB 5.4 Preview 4 and the latest Segger package.

Then use the “reset device” checkboxes on the Debug Settings page or expand the “Advanced” view to directly edit the J-Link gdb server command line and/or startup commands.

If it doesn’t work, please attach a screenshot of your settings.

[support]

Hi,

Unfortunately this looks like an internal error in the gdb debugger. The only advice we could give here is to understand what is triggering it and try avoiding it, sorry.

[Author]

Posts