Forum Replies Created
-
Posts
-
No problem. We have updated VisualGDB to show the output messages from TinyEmbeddedTest in Test Explorer. Please try the following build: VisualGDB-5.5.2.3357.msi
Please make sure you update to the latest Profiler/Semihosting and TinyEmbeddedTest framework versions after installing the new build. Then try creating a simple TinyEmbeddedTest-based project and run its tests. The test window will show the output from test #2.
We have also added an option under VisualGDB Project Properties -> Embedded Frameworks to redirect all regular printf() output to the test output.
Sorry for the delay. We have done some experiments and added a target API that allows distinguishing between the regular debug sessions (launched via Debug->Start Debugging) and test run/debug sessions launched via Test Explorer.
Please try the following build: VisualGDB-5.5.2.3357.msi
Please also update the Semihosting/Profiler and TinyEmbeddedTest frameworks via Tools->VisualGDB->Manage VisualGDB Packages after installing the new build.
Then try creating a new TinyEmbeddedTest project and see how RunAllTests() is now called conditionally:
if (IsRunningUnitTests()) RunAllTests();You can use the IsRunningUnitTests() call in your code to switch between running the main application logic and passing control to the test framework.
If you would like to remove the tests from the final binary, please consider creating a separate configuration (e.g. Debug + Tests), defining a macro (e.g. INCLUDE_UNIT_TESTS) via VS Project Properties and checking for it in your code.
Hope this helps. Let us know if you have any further questions or suggestions.
Hi,
Sorry, our external FLASH plugin mechanism is only intended to be used with VisualGDB. It will not work with the ST-Link programming tool, or any other software.
If you are using VisualGDB, you can program the FLASH memory without launching a debugging session via Debug->Start Without Debugging or Debug-> Program FLASH Memory.
Regarding the external memories, you can indeed get it to work by modifying the linker script manually, however you would need to make sure you fully understand the linker script logic first, as incorrectly using some of the linker script parameters would make the built file unusable.
If you prefer something that works out-of-the-box, please consider upgrading to VisualGDB Custom Edition here and then use the External Memories page of VisualGDB Project Properties to automatically edit the linker script as expected.
No problem, we can help you get this to work, however we would need more information in order to pinpoint it.
The error stack you attached looks like the New Linux Configuration Wizard is getting invalid/incomplete information about the current project. If the solution contains multiple projects, it could happen if the currently selected project (i.e. the project owning the currently selected item in Solution Explorer) is some special type of project that is not properly recognized by VisualGDB.
In order to diagnose it further, please try this build: VisualGDB-5.5.1.3349.msi, it should include more details in the error traces.
Please share the updated traces from:
- Using the New Linux Configuration wizard
- Using the New Linux Project wizard
If you could also share a screenshot of the Solution Explorer showing the currently selected item while trying to import the project, it can help us pinpoint the issue faster (you can send it via our support form if you don’t want to post it publicly).
Hi,
Sorry, the embedded test frameworks also require the profiler/semihosting framework, that needs to be enabled separately via VisualGDB Project Properties -> Embedded Frameworks.
Generally, we would advise creating a new test project from the wizard. Now that you have the Custom edition, it should work out-of-the-box, referencing the necessary libraries generating the necessary initialization code.
Once you can confirm that testing a newly created project works, please try referencing both the profiler framework and the unit test framework from the existing project and then ensure its main() function looks similar to the main() function of the generated test project.
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.
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++>
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.
If you know the directory where the Makefile is located, please simply select the following:
- Project Type: Import a project -> Import a project built with other tools
- Source code location:
- The sources are located under the Linux root filesystem
- Source directory: the directory where you have the Makefile (Linux-style path such as /mnt/c/foo)
- Building and debugging:
- Build command: make
- 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.
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.
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:
- 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.
- 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.
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.
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.
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.
