Forum Replies Created
-
Posts
-
For MSBuild projects, the VisualGDB-level variables should not be automatically propagated to MSBuild level, unless you configured some mechanism to do it manually. If you can share the screenshots of your setup (how you configured the variables and how do you observe them propagated), we will try to explain what is going on.
Hi,
No problem. Please let us know the email address associated with your license key, and we will look further into it.
Hi,
The ESP-IDF projects support multiple targets per project (i.e. libraries/components), hence typically there is only one project per solution, even for complex projects with reusable code. While having multiple ESP-IDF projects in the same solution is supported, it is somewhat a rare case and it may indeed not be 100% perfect. More specifically:
- The recompilation is managed by the ESP-IDF itself. VisualGDB simply invokes CMake/Ninja to build the project. You can try adding “-v” to Ninja arguments to see what is going on, but either way it’s not directly controlled by VisualGDB.
- You can reload the projects one at a time by right-clicking on them and selecting “Reload”. The initial loading after opening the solution will indeed be done simultaneously. As multiple ESP-IDF projects is a relatively rare case, we will not be optimizing this specific part, sorry.
- As most ESP-IDF-based setups use one project per solution, the test logic indeed doesn’t show the project name. If you have to use multiple ESP-IDF projects in the same solution, please consider answering “no” in the initial prompt and reloading projects one-by-one via context menu. This will show the prompts for the corresponding projects separately.
- This again comes from the way the ESP-IDF framework supports tests. You can try patching the ESP-IDF scripts to only build unit tests when a specific configuration variable is defined. If this gets the tests working via command line, but not in VisualGDB, we can try updating VisualGDB to recognize them properly unless it would require a large amount of changes.
No problem. Feel free to share an update here once you get the steps we could follow to reproduce the problem, and we will look further into it.
Hi,
If you prefer using GNU Make, you can always patch the Makefile to change its layout and support multiple folders, however it is something for you to setup and test.
On our side, we have designed the MSBuild-based and CMake-based projects specifically to address numerous shortcomings of GNU Make, and advise using them instead.
MSBuild is fully compatible with CI/CD – you can simply generate a batch file with all commands: https://visualgdb.com/documentation/projects/msbuild/#standalone (although you would need to programmatically replace absolute paths in it and in the .rsp files).
Hi,
The IsRunningUnitTests() function is a run-time check, rather than a compile-time one. If you have trouble finding it, please try following our unit test tutorial with exactly the same device and framework as shown (you don’t need to run the code) and use Go-to-definition to locate it. You will then get a reference point that can be easily compared against your project.
If following the tutorial doesn’t work, please attach the relevant screenshots showing the difference, and we will try to help you.
Hi,
This means that VisualGDB is working as expected – it is resetting the device. It is hard to say why a particular program would not be working after a soft reset. You can try ensuring that the reset works for a basic “Blinking LED” program, and then comparing it side-by-side with your one, until you find what is causing the difference. If you prefer, we can also gladly do it for you via a screen sharing session billed at our consulting rate. Feel free to contact our sales if you would like to get more details.
Hi,
Most likely, your program has a non-trivial structure, and injecting the instrumenting logic in it breaks something. You can troubleshoot it by configuring VisualGDB to stop directly at the entry point (VisualGDB Project Properties -> Embedded Debug Tweaking -> Step into new instance) and then stepping through the initialization code to see what is going on.
Another option would be to compare the <ProjectName>_instrumented.elf with the original ELF file produced by the project (e.g. using objdump) and double-check that the inserted instrumentation-related sections don’t overwrite anything.
You can see the log explaining the placement of the instrumentation sections by enabling View->Other Windows->VisualGDB Diagnostics Console before launching a debug session.
Hi,
VisualGDB indeed requires the Visual C++ for Desktop Development in order to create most project types, as shown in the documentation page you linked. If you are not able to install it, please consider contacting Visual Studio support for help.
Hi,
This is not supported for Makefile-based projects. Please consider using CMake or MSBuild instead.
Hi,
No problem. You can review what is going on by enabling the gdb logging as shown here. Normally, if you do not program the device each time, VisualGDB will simply reset it using the “mon reset init” command.
Please try checking the gdb log file and make sure it contains the reset command. If not, please ensure one of the reset checkboxes is set in VisualGDB Project Properties -> Debug Settings.
If the reset command is present in the log file, please try running it manually and checking if it manages to reset the device correctly.
Hi,
Indeed, the MSBuild-level properties are separate from the VisualGDB variables and are not automatically inherited.
The easiest way to achieve what you have described is to programmatically generate an MSBuild property sheet defining the necessary variables. You can reference the property sheet from one or more projects, and can invoke the tool generating it as a custom pre-build step.
Another option would be to simply generate a header file with the relevant definitions, and include it from the projects.
Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
- The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.
You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.
Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.
Thanks for clarifying this. If the toolchain is not based on GCC, you can simply create a custom Makefile for building your code and import it into VisualGDB as an externally built project. This way VisualGDB will simply invoke make with the specified arguments to build the project and won’t care that the underlying tools are not based on GCC. If the tools report error messages in a non-typical way, you can tweak VisualGDB to recognize them by editing %VISUALGDB_DIR%\Rules\RegularExpressions.xml.
On the debugging side, if the vendor provides a gdb executable for their platform, you can use VisualGDB to debug the code by overriding the gdb path via VisualGDB Project Properties. If they use a completely proprietary debugging protocol, we can still add support for it as a custom paid feature, but it would be a rather complex one.
Hi,
We provide out-of-the-box integration for mainstream devices with many active users, however this looks like a much more niche device with a smaller user base. Hence, we will not be supporting it directly unless some of our users agrees to directly cover the cost of integrating VisualGDB with it.
That said, VisualGDB is designed to be very flexible. If the device vendor provides a GCC-based toolchain, you can simply import it into VisualGDB by using the import link in the toolchain selector. Then, you can follow this tutorial to manually specify the compiler flags and locate the driver files necessary for that device. This way you can enjoy most of the VisualGDB functionality even if the device is not directly supported by us.
