[support]

Hi,

No problem, please find the answers below:

1. If you are not using the Custom edition, you can only have 1 version of the SDK installed at once. It doesn’t have to be the latest version from our servers, but it has to be the same version for all the projects. If you want to use multiple versions without upgrading to the Custom edition, you can simply rename the BSP folder and edit the ID in the BSP.XML file – VisualGDB will then treat it as a separate BSP. You can then switch projects between different versions of the SDK by editing the BSP ID in the nrf5x.xml file.
2. The “shared files location” points to a directory of the VisualGDB-supplied BSP package. It is generated from the original SDK and includes fixes necessary for the project to build out-of-the-box (e.g. patches to linker scripts that allow including the softdevice into the main project binary). You can download BSP packages generated from older SDKs here and install them via VisualGDB Package Manager, however using the raw SDK itself won’t work as it will not include the necessary patches. Our tool for generating the packages from the original SDK is open-source through, so you can experiment with it if you want to support some specific version of the SDK (note that SDK 15.0 support is currently in development and is close to being released).
3. The Embedded Frameworks is a convenient way to add sources and include directories from various nRF5x components to the project. It doesn’t edit the configuration file and only affects the list of source files, include directories and sometimes preprocessor macros. You can find out what exactly each framework does by locating the <EmbeddedFramework> element in BSP.XML, however for Nordic devices the frameworks are just convenience wrappers around the corresponding directories in the SDK.

[support]

Hi,

We are not aware of this issue, so it might be caused by some project-specific configuration (e.g. mismatch between the project and the ESP-IDF version). Normally the ESP-IDF configuration entries are handled by the ESP-IDF itself, so VisualGDB should not change the related logic.

Does the issue happen for any newly created project, some newly created projects, or a specific project you are trying to import? If it is limited to a specific project, does the error also happen when building it from command line?

[support]

Hi,

This is already supported (using the same semantics as PuTTY) – any text selected in the console is automatically copied to the Clipboard and you can paste text via Shift+Insert or via middle mouse button click.

[support]

Hi,

Yes, we have added a new command-line option to VisualGDB to export test results in the VSTest format to this build. Please use the following command line:

VisualGDB.exe /runtests <settings file> /vsoutput:<file.trx>

Then publish it using the regular “Publish Test Results” task (ensure you select the VSTest format). Let us know if you have any feedback/suggestions.

[support]

Hi,

Good to know it works with the older OpenOCD version.

Based on the debug output you provided, it looks like the issue is somewhere between the libusb library and your USB controller driver. Unfortunately this appears to be specific to either your USB controller, or some additional software installed on your machine, so it’s hard for us to narrow this down. That said, we regularly release new OpenOCD packages based on the latest sources, so if this issue gets fixed by the OpenOCD/libusb maintainers, our builds will automatically pick up the fix.

If you would like to use the latest OpenOCD, our best advice would be to try checking if you have any USB-related software installed (e.g. USB-over-network) and try uninstalling it. You could try running this setup on a different machine to confirm that it’s specific to the USB driver and not to that specific ST-Link instance.

[support]

Hi,

It looks like the command-line mode might be leaving ST-Link in a state where it doesn’t respond to regular commands. A short-term workaround would be to simply plug it out and back in.

Long-term, please let us know how to reproduce it. Are you simply using VisualGDB.exe /runtests, or some other way to run the tests?

[support]

Hi,

One of the ways to migrate the code would be to create a new project and then add existing sources (either one-by-one, or via Add->Import Directory Recursive command provided by the Custom edition).

Another option would be to select “Import Existing Project” in the VisualGDB Project Wizard. It will let you pick a folder with your source files and will add them to the created project.

[support]

Hi,

The TinyEmbeddedTest framework is intended to be used with the barebone devices that don’t have a concept of command line (unless you are using semihosting anyway), so it doesn’t support any command-line switches. Instead you can use the Visual Studio GUI to select which of the tests to run.

If you are running tests via the VisualGDB.exe /runtests command line, we could add an option to run specific tests only there as well.

[support]

Hi,

We could easily add a registry setting that would override the temporary directory for downloaded files. Would that work for you?

[support]

Hi,

Normally VisualGDB should display a manual activation window if there is no Internet connection. If you don’t have Visual Studio installed on the build machine, please try running VisualGDB.exe /about to open the “About VisualGDB” window and enter the license key there.

[support]

Hi,

VisualGDB internally uses a lightly patched version of libssh2 to handle the SSH connections, so the “handshaking” delay must come from inside this library. Unfortunately investigating this on our side and optimizing the library is beyond what we could offer with our regular VisualGDB support, however if you managed to narrow this down to a specific change to libssh2 and send us a merge request, we would be able to integrate it into VisualGDB.

[support]

Hi,

Please refer to the following page for instructions on troubleshooting this: https://visualgdb.com/support/nodevice

[support]

Hi,

Thanks, looks like our bug. We have fixed it and released an updated STM32 BSP. Please update it via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Hi,

The license key should not be related to this – the problem you are encountering occurs between OpenOCD and ST-Link and the license key only affects VisualGDB.

Most likely the connection fails due to one of the following reasons:

• The ST-Link itself got damaged. This can be checked by trying to connect to it via the ST-Link utility (also updating firmware to the latest version might help).
• The drivers for the ST-Link got corrupted. Uninstalling the driver and reinstalling the regular ST-Link driver from ST might help.
• Some USB virtualization/forwarding software is interfering with ST-Link. Disabling any software of this type might help.

[support]

Hi,

If the framework changes, VisualGDB won’t replace the entire file list overriding your changes. Instead it will add the new sources to the project, keeping the “does not build” flag for the old ones.

If the new source files only contain functions/methods used by the old ones, the linker will automatically eliminate them (as long as other files are excluded), so you won’t need to update this manually.

Long term, we will solve this by fully supporting the Advanced CMake Project Subsystem for embedded projects – the frameworks will be converted to separate CMake targets and you will be able to fine-tune the references by editing the CMake files, although this will be added after the upcoming v5.4.

[Author]

Posts