Forum Replies Created
-
Posts
-
No problem. We have updated VisualGDB to correctly recover from the corrupt directory synchronization records. Please try this build: VisualGDB-5.6.2.4169.msi
Hi,
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.
Hi,
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.
Hi,
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.
Hi,
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.
Hi,
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.
Hi,
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.
Hi,
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.
Hi,
It looks like your support period has expired a while ago. Please kindly renew it here and update to the latest VisualGDB build (VisualGDB-5.6.1.4153.msi). If the option still doesn’t show, please send us a screenshot of the settings window where you would expect the option to be, and we will help you troubleshoot it.
Hi,
We are planning to look into CC3220 update in the next 4-5 weeks. We will post an update here once we have a new BSP available.
Thanks for renewing your support. The option should be available in VisualGDB 5.5R5. If it doesn’t work, please try the latest development build here: VisualGDB-5.6.1.4153.msi
Hi,
Most likely, your proxy server/firewall does not support multi-threaded downloads and ends up corrupting the downloaded file.
You can disable the multi-threaded downloads by setting Tools->Options->VisualGDB->General->Other->Parallel download threads to 1, or simply try downloading the toolchain manually from https://gnutoolchains.com/
If it reports zero data, VisualGDB will indeed not able able to show anything meaningful, because all it gets is zero data. As we have suggested before, please check this with Segger support – they should have a better insight on what is going on inside the Segger GDB stub and why it doesn’t report the correct values.
Hi,
This could indicate a hardware problem with the tracing pins, or wiring issues. You can try checking the low-level tracing functionality by disabling the Live Tracing, starting a debug session, and running the following commands in the GDB Session window:
- maint packet qSeggerSTRACE:config
- maint packet qSeggerSTRACE:caps
- maint packet qSeggerSTRACE:start
- [step over a few instructions]
- maint packet qSeggerSTRACE:read:4
If the last command does not return non-zero data, the Segger GDB stub is not reporting the tracing data correctly. If this is the case, please double-check all the wiring and consider contacting Segger support for further help.
