Forum Replies Created
-
Posts
-
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.
If the ls/stat commands produce output that looks valid, but doesn’t match the actual state of the file system, it could indicate a filesystem corruption or some other strange bug.
In generally, VisualGDB needs a reliable way to find out the name of the file that was created in response to the “dump” command. Our best advice would be to experiment with different modes of ls, stat and also run the dump command multiple times to understand why they don’t work on that target. In generally, the output from the file listing command after running the dump command should contain exactly 1 more entry starting with “callgrind.out”.
Hi,
Building MSBuild-based VisualGDB projects does require VisualGDB, since it provides the actual build rules for them (see this page). However, you can easily dump the build steps for your project into a batch file (see this page), check it into the source control, and run it on the build server. You will need to patch the batch file and the .rsp files it to replace the absolute paths with proper variables, but it should be a good starting point anyway.
If generating the .bat files is not an option, you would nee to make sure that the build server has the same Visual Studio configuration as the development machine (including MSBuild toolsets, etc.). You may also be able to get it working with a smaller MSBuild installation, although you would need to manually track down the error messages (they usually show the .props/.targets file where the error happens) and adjust the project accordingly (e.g. define some variables that the stand-alone installation expects). Generally, this is something to do at your own risk – using the batch files or getting a full VS installation should work much more reliably.
Just wanted to clarify that if any of our users are interested in taking this project, please feel free to contact @GeneM.
We are currently working on a few VisualGDB customizations requested by our large customers and have no resources to take it in the near timeframe.
This error happens with VisualGDB requests Valgrind to dump the current information gathered by the profiler into a dump file. Normally, it would create a new dump file in the Valgrind session directory (/tmp/2e48884f-d532-4289-9e0b-2e1378af5121 in this case), however due to some reason, Valgrind does not create it in this case, or VisualGDB fails to locate it.
In order to troubleshoot it further, please try following the steps below:
- Enable View->Other Windows->VisualGDB Diagnostics Console.
- Start a profiling session with debugging and wait for it to trigger on a breakpoint.
- Locate the valgrind launch command in the diagnostics console and find out session directory from the –vgdb-prefix switch.
- Check the contents on the session directory manually.
- Try running the “monitor dump” command in the GDB Session window.
- Check if this created any new files in the session directory.
If Valgrind did not create any new dump files, it could be a bug of Valgrind. Trying other configuration options, or a newer Valgrind version might solve the problem.
If the new dump file was created, the remote system might be missing the ‘ls’ or ‘stat’ commands used by VisualGDB to query the file list. You can locate the exact command lines used by VisualGDB (e.g. cd “/tmp/34f1e35f-a7e2-4b00-b34c-24659c90a8f5” && ls -1A | xargs -d “\n” stat -c “StatEntryL:|%N|%Y|%d|%s|%f” .) in VisualGDB Diagnostics Console and try running them manually to see if they work on the target. If you get any errors from running that command line, please let us know and we will investigate it further.
Hi,
Sorry, this looks like a bug of the gcc compiler and not a VisualGDB-specific issue.
Our best advice would be to try reproducing it in a command-line build (if you are using MSBuild, you can configure it via VS Project Properties to create a .bat file with all build commands) and try posting in the GCC mailing list.
Another option would be to try using the Keil or IAR compiler instead of GCC. VisualGDB supports both of them and they generally provide a better optimization than GCC, and come with their own support.
Sorry, this is only officially supported for the ARM devices.
You could try extracting the heap parsing logic from our FreeRTOS plugin and creating a custom expression visualizer based on it, but it will involve non-trivial coding.
Thanks for renewing your support.
We indeed no longer include the GNU Make executable with our toolchains. Instead, we have switched them to using make.exe from the VisualGDB directory. This should automatically apply to newly created projects. However, if you have created your project with an older version of toolchain, it would need to be updated manually. If this is the case, please try setting the Make path in VisualGDB Project Properties -> Make Build Settings to $(VISUALGDB_DIR)\make.exe.
You can also simply copy make.exe from the VisualGDB directory to the toolchain directory if you do not want to edit the project file.
No worries. Just please be aware that the 50% renewal discount we give for VisualGDB always extends the previous expiration date by 1 year, regardless of the actual date of purchase. So unless you have a very old license that doesn’t qualify for the regular renewal discount anymore, there is no advantage of delaying the update.
Also Microsoft has recently switched to faster release of VS updates that often break backward compatibility or introduce new issues (e.g. VS16.10 broke IntelliSense interface compatibility with older VS2019 builds). We usually release hotfixes for these issues very fast, but they do require an active license.
