Forum Replies Created
-
Posts
-
Please contact our sales at sales@sysprogs.com for details about the number of machines.
The Visual Studio compiler and GCC are not 100% compatible when it comes to complex C++ templates. You may need to adjust your code so that both compilers can handle this (the problem is well-known, so googling for specific errors should easily get the fixing instructions).
You can specify -std=c++11 or -std=c++14 in CFLAGS on the Makefile Settings page of VisualGDB Project Properties.
Hi,
Please add the directory containing the missing header file to the “Include Directories” field on the Makefile Settings page of VisualGDB Project Properties. Adding the file to the Solution Explorer simply makes it easier to open, but does not affect search paths used by the #include<> directives.
Hi,
Please ensure that the jni folder is located directly inside the “C:\Users\nzmora\AndroidStudioProjects\CameraProcessor\app” folder.
If this does not help, please share a tree of all files (cmd /c tree /f > tree.txt) in the project directory.
This does not indicate an error. It just means that those tools are not present in your toolchain and VisualGDB will use the Windows equivalents. In fact, VisualGDB 5.0+ does not show the ‘X’ even if the tools are missing, as this sometimes causes confusion.
Hi,
VisualGDB uses a different syntax for displaying pointers as arrays. Please use the following expression:
*foo@length
Most likely the problem happens because Visual Studio confuses some of the files downloaded from the remote machine with its own project files and refuses to create the project.
Please share the following:
- The exact directory of your project and the project name
- The screenshot of the message
- The contents of the directory when Visual Studio shows the error message
This should help us understand which files could be interfering with Visual Studio project creation.
Hi,
Actually one of our customers has contributed a package already and we are currently reviewing it and will be publishing an official one within the next few months.
We can provide you with the current version on the “as is” basis if you want to try it. Please email our support to get a download link.
Looks like the first problem is caused by some broken symlinks on the Linux side. You can investigate this by running “ls -l” in the target directory and checking that all symlink targets exist.
The glibc problem can be caused by incompatibility between your toolchain and the system image. Please try the instructions described here: http://sysprogs.com/w/forums/topic/raspberrypi-undefined-reference-to-clock_gettimeglibc_2-17/
Hi,
VisualGDB Linux edition can only upload sources from one directory (with arbitrary subdirectories), so you can simply change the source directory to point to the parent one if that helps. If your source files are scattered around several directories, you would need additional file transfer actions that are available in the Custom edition and higher.
Note that if you have purchased a license recently, you can upgrade from Linux to Custom for just the price difference.
Hi,
We have looked into the new TI MSP430 toolchain. Although it is based on the newer tools, it currently contains one major bug: if you use the -ffunction-sections flag that helps removing unused code from your binary, the debug symbols become unusable.
We have repackaged the toolchain (without TI proprietary tools) and uploaded it together with a one-click installer here: http://gnutoolchains.com/msp430/
Remember to remove the -ffunction-sections flag from the debug configuration flags, as otherwise you won’t be able to debug your code.
Hi,
Thank you for your feedback. We indeed did not update the MinGW64 toolchain because there is not much demand for it among our users. For the popular areas (like embedded ARM, supporting new Linux-based platform, etc) we do actually publish updated toolchains.
Furthermore, VisualGDB is not limited to a specific set of toolchains! You can use any MinGW release you wish. Simply point VisualGDB to it and it will be able to integrate with it. That’s why instead of rebuilding something that already exists we focus on adding usability features, quick setup features and state-of-the-art IntelliSense.
If you say VisualGDB is absolutely not worth it, you could try setting up Eclipse with the same toolchains. However you would quickly find that many time-saving features provided by VisualGDB are missing there. Regarding your .Net suggestion, thank you for it, we will address it in the next release.
Hi,
VisualGDB currently does not support merging changes between the Linux and the Windows checkouts. The easiest workaround would be use a Windows SVN client to check out the repository on the Windows side and do an update there as well so that SVN can handle change merging for you. During the next build VisualGDB will only retransfer the changed files to the Linux machine.
Thanks for pinpointing the typo, we have fixed it.
Hi,
Sorry for the misunderstanding. The “MemU32” command is handled by the Segger GDB stub directly, so the caching actually happens inside the Segger stub.
From a quick look (“mon help” command) it seems that it does not have a specific command for resetting the cache. Please try one of the 2 options:
1. Contact Segger support. They should be able to suggest a workaround or release a hotfix.
2. Try using OpenOCD. It is less stable and usable than the original Segger software, but it may not have the cache problem.
If nothing helps, ensure that the problem is not caused by the CPU cache. Try reading one specific word from FLASH to a local variable in your firmware and examine the value of this variable using the debugger. If the value is also wrong, you need to reset the CPU cache.
