[support]

Sorry, unfortunately it looks like the detail level you require is beyond what we can offer with our product support. VisualGDB is a productivity tool that automates common development tasks and provides convenient GUI for common routine operations. However, it still relies on the understanding of basic programming concepts and the ability to troubleshoot issues inside the code or build scripts that do not come from us.

While we are happy to point to a VisualGDB setting that allows specifying the PATH variable, it is beyond the scope of our support to suggest a specific path string that will work with a specific project.

We are sorry if this is not what you expected from our support, however we have to find a trade-off between covering underlying low-level tools while charging 10x-20x more per license, and restricting support to VisualGDB issues only while keeping our product price more affordable. We do offer paid consulting with hourly billing to bridge the gap between the 2 options, however it isn’t possible for us to provide this level of detail at the price of a regular license.

[support]

This means that the gcc executable is not in the PATH variable.

Please try running the “arm-none-eabi-g++” from the bash command line, take note of its location (directory containing the executable) and add the following environment variable to VisualGDB Project Properties -> Build -> Build Command -> Environment:

PATH=%PATH%:<directory containing arm-none-eabi-g++>

 

[support]

This is likely a VisualGDB bug caused by a recent change in the WSL path mapping logic.

Please try the new build linked in our previous reply (VisualGDB-5.5.1.3339.msi). We have removed the Source Code Access page for Linux Subsystem projects there to avoid any confusion, so the bug should no longer trigger.

[support]

If you know the directory where the Makefile is located, please simply select the following:

1. Project Type: Import a project -> Import a project built with other tools
2. Source code location:
   1. The sources are located under the Linux root filesystem
   2. Source directory: the directory where you have the Makefile (Linux-style path such as /mnt/c/foo)
3. Building and debugging:
   1. Build command: make
   2. I don’t know the main executable yet.

The “Source Code Access” page is intended for setups involving Linux machines accessed via network and can be ignored when using LXSS.

We have not anticipated it to cause that much confusion and have removed it for imported Linux Subsystem projects in the following build: VisualGDB-5.5.1.3339.msi

Please try the new build, it should make the importing process very straight-forward.

[support]

Unfortunately, we cannot provide the exact settings that will successfully build a 3rd-party project that we have never seen before. We do not know the directory where you have stored it. We do not know the structure of the project. We do not know where is its primary Makefile located. We do not know if if requires any additional configuration steps. This is something you need to understand before importing the project, as without this information it is not possible to configure VisualGDB (or any other IDE) to build it.

The settings your mentioned appear correct, however based on the error log you provided, the directory you specified while importing the project (/mnt/c/Users/kentm/source/repos/kocherga-demo) does not have a Makefile, hence the build fails.

Please share the command line (and the output) you use when building the project manually under the Linux subsystem (including the “cd” command for entering any directories) and we will share instructions on updating your current setup to replicate that build.

[support]

Thanks for clarifying your constraints and good to know debugging works. Your description of the debugging setup matches what we described.

Regarding building, combining the WSL for building the projects with the regular embedded workflow for debugging them is not trivial. Because it introduces many additional breaking points, we normally do not recommend doing it unless you are familiar with the Linux internals and are prepared to troubleshoot Linux-related issues. As it is a very rare scenario, we do not intend to support it out-of-the-box and would advise choosing a different approach if you do not wish to go deep into the Linux build tool internals. Hence we can offer the workaround below.

Please consider creating 2 projects in the solution: one for building the code (linux project wizard->import a project->import a project built with other tools->Use W10 linux subsystem) and another one for debugging the code (the one you have just created). You should still be able to build the code via Build->Build Solution and will be able to debug it by debugging the debug-only project. If the imported Linux project doesn’t build, please attach the screenshots of your build settings, the error about the missing arm-none-eabi-g++ file and the output from running “which arm-none-eabi-g++” in the WSL’s bash console. Then we will help you modify the build settings to find arm-none-eabi-g++ as expected.

We are sorry our responses require follow-ups. We tried answering as soon as possible (about 30 minutes from your inquiry), hoping that it would not introduce much delay. Unfortunately, as you requested a very specific setup that is not directly supported, we need to understand more about your constraints in order to suggest a reasonable trade-off. If you are looking for a fast turnkey option, please consider one of the 2 following options:

1. We can offer you a paid screen sharing session where we will analyze your existing project, explain the roles of the low-level tools required to build it, make the necessary build scripts and make sure everything matches your expectations. Because this is specific to the project, we charge an hourly fee for this and are not able to include it in a regular product support.
2. We can also offer you our paid project conversion service. If you could send us the project archive, we can give you a quote for converting it to an MSBuild project fully managed by VisualGDB. Once the conversion is over, you will be able to use the regular Visual Studio GUI to edit various project properties and will not need to fight the Linux tools ever again.

 

[support]

Yes, VisualGDB 5.5 includes numerous fixes, but also introduces new functionality like the new Advanced Build Log View that might still have some sharp edges due to the preview/beta status. We offer both versions for download so that our customers can make a choice between a more functional and more stable version depending on their constraints.

[support]

Good to know it works. The latest OpenOCD package is compatible with both VisualGDB 5.4 and 5.5 Preview, so as long as the developers can the Tools->VisualGDB->Manage VisualGDB Packages->Updates command to install it, they should be good to go.

[support]

No problem, we will try to help, however we would like to clarify one thing first.

Is there any specific reason why you need to use WSL? This sounds like a very complicated setup that indeed requires non-trivial manual configuration and if you are not familiar with the Linux internals, it would be much easier to convert the project into a format where VisualGDB fully controls the build and abstracts away the low-level tools and settings (e.g. MSBuild).

If this is an option, we can help you understand various MSBuild-related settings so that you can replicate most of your existing project’s setup in an environment fully managed by VisualGDB.

[support]

No problem. We have updated our OpenOCD package to include the latest fix.

[support]

Thanks, this makes sense. It looks like you are using a VisualGDB edition that doesn’t support unit tests (Unit Tests, Profiling and other advanced features are supported starting from the Custom edition per our feature matrix). Most likely, you have created the initial project during the trial (that included the features from all editions) and then once you purchased an edition that does not support unit tests,  the related functionality was disabled.

You can always upgrade your key using the following page: https://sysprogs.com/splm/mykey. If you have purchased it recently, the upgrade price will be just the price difference between the editions.

[support]

Thanks, it looks like the project was indeed missing the test framework-specific directories and macros (specifically, the nrf5x.props file must contain the SYSPROGS_TEST_PLATFORM_EMBEDDED string).

We have tried regenerating the test-related properties by opening VisualGDB Project Properties -> Unit Tests, unchecking and checking the “This project contains unit tests” checkbox and clicking “Apply” and VisualGDB successfully inserted them in the .props file (see attachment).

If it doesn’t work on your side, most likely some global setting on your computer is preventing VisualGDB from saving the test framework settings to the .props file. If this is the case, please try opening View->Other Windows->VisualGDB Diagnostics Console and then create a new test project from scratch. If the problem persists, please share the entire diagnostic output produced by VisualGDB and we will help you get everything to work automatically.

Attachments:

You must be logged in to view attached files.

[support]

It still looks like the embedded framework parameters (namely the SYSPROGS_TEST_PLATFORM_EMBEDDED macro) did not get applied to the project. Unfortunately, it’s hard to say what is causing it without knowing either all the choices you make in the wizard, or seeing the project generated by it (specifically .vcxproj, .mak, .props, .xml and .vgdbsettings files).

[support]

Hi,

Sorry, using WSL for embedded projects isn’t directly supported, however there is a good workaround for it.

Please try importing the project as a command-line project using our regular ARM toolchain (you can start with a dummy build command line as it won’t affect debugging). Then specify the location of the ELF file and use the regular debug settings. This will use the gdb executable from our ARM toolchain to debug the ELF file produced by the WSL (if your target is a barebone STM32, they should be compatible). Note that you will need to point VisualGDB to the ELF file that contains symbols, not the stripped .bin file.

You can use the Breakpoint Diagnostics window to set path mappings like /mnt/c <=> c:\ so that  VisualGDB will know how to handle the WSL paths.

Once you get debugging to work, you can configure project building by creating a WSL shell script that will go to the project directory and launch Make, and then specifying “bash.exe <shell script>” as the build command line so that VisualGDB will hand off the build to WSL.

If it doesn’t work or you need more details, please let us know and we will be happy to help.

[support]

Hi,

No problem, we can help you get it to work. We have quickly retested the configuration shown in the tutorial and could not reproduce the problem.

Please double-check the following:

1. Check whether the problem affects both build and IntelliSense, or IntelliSense only (i.e. if build succeeds).
2. If the problem affects the build, double-check that the stm32.props file should contain the $(TESTFW_BASE)/com.sysprogs.unittest.tinyembtest text in the AdditionalIncludeDirectories element.
3. If the text is present, check if the %LOCALAPPDATA%\VisualGDB\TestFrameworks\com.sysprogs.unittest.tinyembtest directory contains the TinyEmbeddedTest.h file. If not, please try re-downloading the test framework via Tools->VisualGDB->Manage VisualGDB Packages.

If nothing helps, please try archiving your project (ensure you remove the temporary files) and attaching it here and we can check what is going on.

[Author]

Posts