Forum Replies Created
-
Posts
-
Hi,
No problem. If Visual Studio locks up, please try obtaining a stack trace as shown here. If it contains VisualGDBÂ frames, please attach it here along with your VisualGDB build number, and we will investigate further.
The second issue looks like your gdb executable crashes. Please first make sure you can debug your program manually by running gdb manually on the same machine and with the same gdb you are intending to use with VisualGDB. If you can do that without crashing, we can gladly help you configure VisualGDB to replicate the same setup.
If the toolchain appears broken and doesn’t work, we can also gladly investigate it your you and build a custom toolchain that will work with your target. Feel free to reach out to our sales if you would like to get a quote on that.
Hi,
No problem. Please refer to our MSBuild documentation page for a detailed description of different files used by VisualGDB projects.
Hi,
Thank you for attaching the screenshot. We could definitely add a setting for controlling the code page used by VisualGDB when parsing the gdb output if it was affecting one of our paid users. Please consider purchasing a license and we will be happy to add this setting.
Hi,
Please attach a screenshot of your Help->About VisualGDB window so that we could see what is going on.
Thanks for the clarification. The user variables defined via VisualGDB Project Properties indeed work differently. Their values are saved to the .user file each time you edit them via VisualGDB Project Properties, and are read throughout the build process.
The variables set via custom build/debug steps only persist until the end of the corresponding operation. For non-MSBuild projects that would be the entire build. For MSBuild-based projects they are guaranteed to persist between multiple pre-build steps in the same sequence, but not between pre-build steps and the actual build.
Hi,
Thanks, this explains it. In this case, due to the way Visual Studio handles project files, it may indeed throw the same exception it does when VC++ support it missing. As a workaround, please try unchedking the “Rename the Visual Studio project to match the imported project name” checkbox on the first page of the Embedded Project Wizard.
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.
