Forum Replies Created
-
AuthorPosts
-
September 6, 2016 at 02:30 in reply to: Error on SSH connection with public key since release 5.2 preview 1 #8979
support
KeymasterHi,
We have investigated this and pinpointed it to an issue in libssh2.
To work around this, we have added support for RSA keys to the upcoming VisualGDB 5.2 Preview 3. It will not work with the regular PuTTY key files, but will work when used in the automatic setup mode using Windows key containers.
support
KeymasterHi,
We are actually working on supporting the new IoT SDK out-of-the-box and expect to release a BSP for it in the next couple of months.
If you want to set it up manually, please refer to the following thread for a discussion about the SDK. https://sysprogs.com/w/forums/topic/nrf5x-iot-sdk-setup-in-visualgdb/
-
This reply was modified 8 years, 10 months ago by
support.
support
KeymasterHi,
Yes, you can achieve this by making a small script that waits for the process to start and then gets its PID and outputs it, then add this script as a custom pre-debug action that will set the AttachPID variable.
Then you can select “Attach to existing instance -> specify PID -> 0” on the Debug Settings page (VisualGDB will show a hint that $(AttachPID) will be used to specify the PID).
So each time you start debugging, VisualGDB will launch your script that will locate the process, store the PID output by it in $(AttachPID) and immediately attach to it as if you had selected the process manually.
support
KeymasterWe would still recommend comparing the .map files of the working and broken projects side-by-side. Significantly different addresses of sections or missing groups of functions could provide good clues on what is going on.
support
KeymasterPlease feel free to share the details on the error you are observing (e.g. a screenshot) and we will be happy to provide further advice.
support
KeymasterHi,
You can setup a remote compilation similar to our Linux project tutorial: http://visualgdb.com/tutorials/linux/
support
KeymasterHi,
The problem with MacOS is that it uses a custom linker tool that itself relies on MacOS-specific API, so it cannot be easily ported to Windows.
You can however use VisualGDB to setup a project that will be compiled on the MacOS side directly. VisualGDB optimizes the file transfer and invocation of tools, so the remote compilation should be very fast if your target system is not slow.
support
KeymasterHi,
If the project works with a normal non-stand-alone version, the easiest way to figure out what is wrong would be as follows:
- Create a normal project again. Enable the .map file generation.
- Copy it to a different directory. Convert it to a stand-alone one. Rebuild it.
- Use a diff tool to compare the 2 .map files. If the differences don’t immediately point to the problem, feel free to post the map files here and we will try to help you locate the issue.
support
KeymasterHi,
If you are using VisualGDB 5.2 Preview 2 or later, you can change those colors via Tools->Options->Environment->Fonts and colors->Text Editor->Code reference, Code reference (C/C++ macro) and Code reference (write).
support
KeymasterHi,
This error usually happens when some libraries are not found in the PATH directories. Please try launching the C:\SysGCC\Beaglebone\arm-linux-gnueabihf\sysroot\usr\local\qt5\bin\qmake.exe executable manually from Explorer and check if it complains about any missing libraries.
Normally VisualGDB should setup the paths automatically, so most likely your toolchain is corrupt (perhaps your antivirus triggered a false positive on some of the DLLs from the toolchain?). Please try reinstalling the toolchain and check your antivirus log for messages about blocked files.
support
KeymasterHi,
Yes, this will be the easiest. You will need a Linux machine (or a VM) to run them though.
We will also consider adding unit test support to the MinGW project wizard to create tests that run directly on Windows.
support
KeymasterHi,
VisualGDB is actually designed to seamlessly run the tests on your device. It will automatically start selected tests only, will gather results and failure details and display them in the Test Explorer window just like if they were running on the Windows machine. So you can test actual hardware issues there and even use them to verify that all the components on your board are working properly.
If there is a reason why you would prefer running the tests on Windows side, please let us know. We will be happy to add support for this if it proves more usable in some cases.
The screenshot in the blog post is taken from the Linux project wizard and is offers more options than the Embedded project wizard.
support
KeymasterHi,
It is hard to say what could be causing this without seeing the build log. Please open the Output window via the View menu and check for additional error information. If this does not help, please send us the build log so that we could help you further.
support
KeymasterHi,
Good to know it works.
Not fully sure what you meant by “Live variables appear in the same management”. Do you mean the menu command to show live variables?
support
KeymasterHi,
Do you mean that you have relocated the project, the toolchain or the BSP? Could you please attach a screenshot of the error, this should help us suggest a quick solution.
-
This reply was modified 8 years, 10 months ago by
-
AuthorPosts