Forum Replies Created
-
Posts
-
This might be caused by a recent change in the VS2019 CMake parser. Our latest build [VisualGDB-5.5.103.3919.msi] was fully tested with this VS version and might resolve the issue.
Regarding CMake, please make sure you understand the difference between running CMake on Raspberry Pi itself, and running it on Windows together with a cross-compiler. The CMake building instructions page does explain it in detail.
Thanks, this version should fully support the conditional breakpoints as expected.
If you could reproduce the breakpoint problem on a smaller project created from scratch, and share the steps for us to reproduce it on our side, we should be able to fix it. Also obtaining a gdb log may provide some extra clues (e.g. gdb might be rejecting breakpoint condition commands).
Regarding Natvis, please try the {*(::MyClassImpl*)m_pImpl} or {*static_cast<MyClassImpl*>(m_pImpl)} syntax instead.
Most likely, you have previously selected an incompatible combination of settings somewhere.
If you could share the exact steps to reproduce the problem from scratch per our problem reporting guidelines, we should be able to help you get it working.
Hi,
No problem, please try the steps below to narrow down the problem:
- Try creating a new project and selecting “Store source files on the Windows computer” on the last page of the wizard. Does it solve the problem?
- Does double-clicking on CMakeLists.txt file in Solution Explorer (so that it opens in a permanent tab) instead of a temporary one solve the problem?
Regarding property sheets, most likely you are using a version of CMake that does not support statement annotations. Please try right-clicking on the target icon in Solution Explorer (terminal icon) and select “Go to Definition”. If there are any issues with CMake, VisualGDB will display a link to detailed troubleshooting instructions.
No problem. Please let us know what Visual Studio version you are using.
Please also try the following steps to narrow down the test problem:
- Open the solution in Visual Studio.
- Open the View->Output window and switch to the Tests view.
- Clear the Tests output.
- Build the project and wait for it to finish.
- Make sure the Test Explorer window is visible and wait until it doesn’t show any progress indication.
- Open the View->Output window again, copy the entire output of the Tests view and post it here.
No problem, please attach a screenshot of the Help->About VisualGDB window so that we could check for common issues.
Hi,
Sorry, there is no special GUI or command to achieve this. You should be able to get this working by patching the Makefile to escape relevant internal variables and pass them to gcc as preprocessor macros, however it requires a good understanding of the inner workings of GNU Make and is unfortunately outside the scope of VisualGDB support.
Hi,
SSH performance should not be affected by updating VisualGDB. Please try installing the previous version and check if the problem persists. If it does, please try deploying the same executable using a different SSH client (e.g. using PuTTY SCP or SmarTTY).
If you can confirm that the problem only happens with VisualGDB, but not with other SCP software, we can help you narrow down the difference and make sure the VisualGDB performance matches the performance of other tools.
Hi,
According to our records, your trial period has expired. Hence, VisualGDB will not work and we will not be able to offer any technical support. If you are looking for a free alternative to VisualGDB, please consider using the Arduino IDE.
Sorry, no current plans. We will keep an eye on the popularity of Rust and will consider support it if it becomes more mainstream.
Hi,
No problem, we will try to help you.
VisualGDB loads the list of unit tests by scanning the binaries (either running them, or looking for specific symbols). Hence, in order for a newly added test to appear in the Test Explorer, you need to build the solution. If it doesn’t help, please let us know what happens after the solution build is complete. Does the Test Explorer window show the progress indicator? Does the View->Output->Test window show anything new?
Switching between the different platforms is necessary because VisualGDB (and CMake itself) defines the toolchain settings (i.e. the compiler to use for all targets) for the entire project. Hence, if you would like to run the tests on the Windows machine, you need to build the platform/configuration targeting the Windows machine. Building embedded code would require switching back to the platform/configuration that uses the ARM toolchain.
That said, you can work around it by having 1 solution with 2 VisualGDB projects around the same CMake codebase. The first project would load the top-level CMakeLists.txt file with the PLATFORM=Hardware macro, while the second project would load the same file with PLATFORM=Simulation (see CMake Command lines to understand what exactly gets passed to CMake). From Visual Studio and VisualGDB perspective, these will be 2 independent projects, one of them producing the ARM binaries, and another one producing Windows binaries. From CMake perspective, it will be the same set of CMake scripts reused between the builds.
Note that it will result in some cross-talk between the projects. E.g. adding a source file to a target within one project will not automatically refresh the same target shown in the other project until you manually refresh the second project via context menu.
Regarding the test frameworks, normally, VisualGDB would run the tests on the hardware. In this mode, it supports GoogleTest, CppUTest and TinyEmbeddedTest. As we have recently added support for simulation platforms (i.e. running tests on Windows), we have ported TinyEmbeddedTest and GoogleTest to support this configuration, but not CppUTest yet.
Ceedling looks interesting, however it appears to be very niche. We would be happy to fully integrate it with VisualGDB, however we would have to bill it as a custom paid feature unless sufficient number of our paid users shows interest in using it.
The regular CTest integration works by scanning the source files for test macros. This is less reliable than the binary-level analysis and does not work when running tests on the hardware (since it involves selecting specific test cases by modifying variables during program startup). That said, VisualGDB support for test frameworks is implemented via interchangeable plugins, so you can try tweaking it to support any case that is not supported directly.
You can add libraries to embedded projects via add_library(), however you would need to manually take care of all the fine details done by add_bsp_based_library(), such as automatic handling of code coverage, whole archive linking, handling of differences between GCC, IAR and Keil, and so on. A better approach would be to define a dummy implementation of add_bsp_based_library() to your Linux configuration and use it instead of the original one.
Hi,
No problem, we will help you get everything working. In order to get VisualGDB to edit the source files, you would need to import your project into VisualGDB and configure path mapping via the Linux Project Wizard (e.g. to first copy the entire Linux directory to Windows, and then upload modified files during build, or to access all files directly on Linux via SSH).
Files that are not covered by path mappings will be indeed downloaded to the AutoDownloadedSources folder, but will not be uploaded back.
If you have configured a path mapping, but the files are still downloaded to the temporary folder, please ensure that the Linux file paths reported by gdb match the paths specified in the mapping. You can find out the gdb-reported paths via a gdb log.
If nothing helps, please attach your gdb log along with the screenshots of your path mapping settings, and we will help you find the right settings.
Hi,
No problem, please follow this tutorial to troubleshoot symbol-related problems. If it doesn’t help, please attach your gdb log and we will help you understand what is going on.
Thanks for letting us know. If the file is missing from the gpdsc file, please feel free to report this bug to ST, as this needs to be fixed on their side.
No problem, we have fixed it in the following build: VisualGDB-5.5.103.3907.msi
