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

[support]

Sorry about that and thanks for the log. It looks like the pointer size did get queried correctly, so it’s hard to say what is going on.

We have added more logging to this build: VisualGDB-5.5.1.3331.msi

Please try enabling View->Other Windows->VisualGDB Diagnostics Console and reproduce the problem. Then attach the lines starting from “Parsing ‘<expression>'” and we should be able to understand what is going on and provide a hotfix.

[support]

Hi,

This part is only relevant for VS2015+ that supports fast up-to-date check plugins (invoked before showing the “Project XXX is out of date” message). It should not affect any other functionality and can be safely ignored.

[support]

Sorry, the log doesn’t seem to have anything out of the ordinary, so the only other option would be to try various reset/reinstall steps suggested earlier.

You can also try using the /ResetSkipPkgs option, although it may not work either.

[support]

No problem, we have reviewed the related logic and found a possible cause. Please try this build: VisualGDB-5.5.1.3330.msi

If it doesn’t help, please send us a full gdb log and we will do a deeper investigation.

[support]

Sorry, that would be a tricky one to diagnose. Visual Studio uses an opaque cache object to store the menu commands from various extensions, and if it gets corrupt, there is no known way to deterministically repair it.

We could recommend a few workarounds, but none of them is guaranteed to work 100%:

1. Try running devenv.exe /Log and checking the ActivityLog.xml file. If it shows a specific reason why VisualGDB is not loading, it might give some troubleshooting clues.
2. If VisualGDB is just not mentioned in the log file, try creating another temporary user account on that machine and see if VisualGDB menus appear there. If they do, try moving out the Visual Studio’s per-user registry keys and folders (under %LOCALAPPDATA% and %APPDATA%) and restarting it. This will reset all per-user settings and should get VisualGDB to show again.
3. Also reinstalling or repairing VS via Add/Remove programs might help.

[support]

Hi,

Complex projects like Qemu usually handle dependencies different from each other, so VisualGDB doesn’t provide any special interface for managing them. Hence, the easiest way to debug a tool like Qemu would be to use the Quick Debug feature.

Another option would be to run the configure step manually, ensure that the “Make” command succeeds from the command line and then import the project as an external project built with command-line tools. When VisualGDB asks for the build command-line, you can specify the following to trigger an msys-based build with the correct environment:

• Command: <path to mingw>\usr\bin\bash.exe
• Arguments: –login -c “cd <directory> && make”

Debugging normally does not require the special environment, hence using the regular settings to specify the debugged executable should work.

[support]

Hi,

Please try installing any other extension via Tools->Extensions and Updates. This should force Visual Studio to rebuild the menu cache.

If it doesn’t help, please double-check whether VisualGDB commands appear under Tools->Customize.

[support]

Thanks for finding this out. We would normally want to avoid modifying the hidapi source code (as it would involve forking it just for that change), so we have instead updated our OpenOCD to replace the serial number received from the command line with a correctly-cased version once a case-insensitive match is found. Please try this build and let us know if it works: https://sysprogs.com/files/tmp/openocd.exe

[support]

Hi,

The VisualGDB’s linker scripts indeed follow a very basic structure. If you would like to make use of the additional memory definitions, please try downloading the XMC Peripheral Library from Infineon and importing the linker scripts from it.

[support]

Hi,

No problem, we have released an update to the Infineon BSP resolving this issue. Please update it via Tools->Manage VisualGDB Packages.

[Author]

Posts