[support]

Hi,

No problem. We will consider updating the wizard controls as a part of introducing the new transfer engine.

[support]

Hi,

VisualGDB takes the VS2017 path from registry. You can find details about this on the following page: http://visualgdb.com/support/loadfail/

Please modify the registry so that it points to the correct VS instance and re-run the VisualGDB installer.

[support]

Hi,

Thanks for the repro project. It looks like you are trying to exclude a directory using the mask for files.

Instead please choose “include selected subdirectories only” and select all subdirectories instead of .build.

We are also working on an improved file transfer engine that will allow specifying more complex rules instead of the current files/directories settings, so feel free to get check back in a few weeks and try the next preview build once we release it.

[support]

Hi,

Strange. Would you be able to create a basic repro project and send it to us? That should be the easiest way for us to see what is going on.

[support]

Hi,

It is hard to say why scanf() would not work with USB, but generally stepping through the _read() function shown in the tutorial should help.

Debugging the USB devices is a bit tricker than the regular embedded code, but is still totally possible. Windows will consider your device “not responding” if it fails to respond to USB requests within a certain time-out (usually in hundreds of milliseconds). Stopping at a breakpoint to examine the program state would trigger this, however adding and removing breakpoints while the program is running would not (it involves a very short stop that VisualGDB handles automatically).

Hence we would advise starting the debug session without breakpoints, getting to the point where the code loops indefinitely and then setting a breakpoint and stepping through it. Stepping through the code will likely time out the USB communication, but it should provide sufficient clues about the internal state of the USB-related logic. Once it breaks, simply disable/remove your breakpoints, restart the device, wait for Windows to discover it and set the breakpoint(s) again.

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

[Author]

Posts