Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
Indeed, the STM32CubeIDE comes with its own fork of OpenOCD and slightly different scripts. You can install an equivalent of it by selecting OpenOCD (ST Fork) as the debug method instead of the regular OpenOCD. Please note that this requires VisualGDB 5.6 or later.
support
KeymasterHi,
Indeed, the .rsp files are generated after all variables have been expanded and contain very low-level instructions to GCC and other similar tools. The easiest work around it would be to use a simple custom script that will patch the paths inside the .rsp files when they are checked out under a different path. This should be still easier than setting up a complete development environment, including VS and VisualGDB on a docker container.
support
KeymasterThanks for renewing your license.
The page on the screenshot you attached is a completely different window from the Visual Studio project properties, and it indeed does not contain the project properties. Please see our MSBuild Documentation page for an explanation how to open the Visual Studio project properties and this section for a specific location of the “Generate a .bat file” setting.
June 23, 2021 at 08:44 in reply to: Remote Linux build with MSBuild dont use built-in variables #30765support
KeymasterHi,
MSBuild indeed uses its own set of variables that work separately from VisualGDB variables. Due to the architecture of MSBuild, unfortunately it’s not possible to easily propagate all VisualGDB variables to the MSBuild level. As a workaround, please consider using MSBuild property sheets. They allow defining reusable variables and targets and importing them from one or more projects.
support
KeymasterHi,
The easiest way to do that would be to generate a .bat file for the MSBuild project on one of the development machines, check it into the source control, and run it on your Docker container. This way you won’t need to worry about installing Visual Studio, VisualGDB or any other tools under docker.
You can find more information about generating batch files for MSBuild projects here: https://visualgdb.com/documentation/projects/msbuild/#standalone
support
KeymasterIf you are using the same version of the tools and frameworks that are shown in our tutorial, it should work the same way.
If you are using a different version, it may indeed work differently, because it is a different version. We do not charge our users each time a new ESP-IDF framework is released, hence we are not able to guarantee that every ESP-IDF version will work exactly the same.
We do test the new releases and update our tutorials periodically, however we prioritize this based on the amount of affected users. The ESP-ADF framework is specific to audio devices, has a relatively small number of users, and is hence a lower priority.
support
KeymasterHi,
Please note that Espressif often changes the internal structure of their frameworks. They often break compatibility with older toolchains, or specific examples. Our support is not able to take over the maintenance and testing of their products, or provide personalized insights into their internal structure. We can only make sure that as long as the ESP-IDF-based project can be built and works otherwise, you will be able to use the VisualGDB GUI to conveniently edit it, instead of manually editing various configuration files.
If you are not able to build the project at all (even outside VisualGDB), please contact Espressif for further help.
support
KeymasterNo problem. We have updated VisualGDB to correctly recover from the corrupt directory synchronization records. Please try this build: VisualGDB-5.6.2.4169.msi
support
KeymasterHi,
This error would generally be shown when CMake reports that the file has code coverage enabled, but the CMakeLists files indicate otherwise. Most likely, something went out of sync at some point.
Please try re-creating the project from scratch and reproducing the problem. If you could share the steps we could follow on our side to reproduce the issue from scratch, we should be able to advise a workaround, or release a hotfix for it.
support
KeymasterHi,
No problem. We have updated msp430-gdbproxy to support the “detach” command. You can download the updated tool here: https://github.com/sysprogs/msp430-gdbproxy/releases/download/v1.10/msp430-gdbproxy-1.10.7z.
Simply replace the msp430-gdbproxy.exe file in your toolchain directory, and it will work out-of-the-box.
support
KeymasterHi,
This error means that one of the automatically synchronized source directories is configured incorrectly. Please try checking the definitions in VisualGDB Project Properties -> Synchronized Directories, and temporarily disabling/removing some of them to see if any specific one is triggering this.
support
KeymasterHi,
Please try checking that the files containing the functions you want to check are instrumented for coverage (i.e. compiled with the -coverage switch). You can verify it by looking for .gcno files near the .o files. If the .gcno files are not present, the code was not instrumented for coverage.
Either way, we would advise first getting it working on a basic project by exactly following one of our tutorials, and then using it as a reference point.
support
KeymasterHi,
VisualGDB supports 2 mechanisms of gathering coverage information:
- Using hardware trace pins. This requires expensive trace probes, but doesn’t slow down the code. The tutorial does mention J-Trace.
- Using code instrumentation. It doesn’t need any special hardware, but slightly slows down the program and uses additional RAM to store the branch counters. This method is described here.
Hope this clarifies it.
support
KeymasterHi,
No problem, we can help you. Please share the complete steps to reproduce the problem from scratch including all the relevant screenshots and we will help you fix it.
Also, please update your forum profile to match the email associated with your license key, or simply let us know your key via the support form.
support
KeymasterHi,
This is correct. We have a detailed API reference and 2 tutorials demonstrating various aspects of the API.
If you would like to support visualizing complex types, we would advise taking time and browsing through the API documentation until you get comfortable with the APIs. If some of the functionality is not working as shown in the tutorials, we can investigate and fix it, but it’s up to you to find the best way to use various features for your specific use case.
-
AuthorPosts