support

Forum Replies Created

Viewing 15 posts - 7,186 through 7,200 (of 7,847 total)
  • Author
    Posts
  • in reply to: Connection establishment take several minutes #3253
    support
    Keymaster

    Hi,

    This might be an indication that your Raspberry Pi board is doing some heavy math on the public keys. Does the password-based authentication also take lots of time? Does the output of ‘dmesg’ contain anything suspicious about regenerating keys?

    in reply to: Fail to Launch GDB Session #3226
    support
    Keymaster

    Hi,

    Sorry, looks like there is a bit of confusion here. Essentially there are 2 totally independent debugging methods:
    1. Using the VMWare stub. In this case VMware serves as a back-end for GDB and the Linux kernel does not even know it’s being debugged. This mode is preferred, as the debugging logic is 100% separated from the kernel and it does not involve a slow simulated COM port.
    2. Using KGDB via a virtual COM port. In this case VMWare does not know anything about debugging, but the kernel itself runs a debug stub (KGDB) that communicates to GDB via a COM port.

    We would recommend setting up the first mode, hence please try checking if you can connect to port 8864 or 8865 on the machine where you run your VM (i.e. where vmware-vmx.exe is executing). Your vmware.log file in your VM directory should contain something like this:

    2014-06-28T11:25:56.622-07:00| vmx| W110: Debug stub: VMware Workstation is listening for debug connection on port 8864.
    2014-06-28T11:25:56.622-07:00| vmx| W110: Debug stub:     target remote localhost:8864

    Please let us know if that works.
    Please note that the COM port settings (e.g. speed) are not relevant in this case, as the debugging mechanisms of the Linux kernel are not being used.

    in reply to: Fail to Launch GDB Session #3224
    support
    Keymaster

    Hi,

    Your VMX file looks like it contains the “stub” setting, so VMWare should be listening on port 8864 or 8865. Are you able to connect to it manually via gdb (target remote localhost:8864)?
    Your GDB log also does not contain the ‘target’ command, so it looks like something breaks before that. Are there any error messages you’re getting?

    support
    Keymaster

    Hi,

    We’ve just added support for debugging over network to VisualKernel 1.1. Have a look at the following tutorial: http://visualkernel.com/tutorials/network/

    in reply to: autocomplete/intellisense problem * SOLVED* #3242
    support
    Keymaster

    Hi,

    What VS version are you using? Are you building a MinGW or a Linux project? Does the Errors window contain any IntelliSense-specific errors?

    in reply to: Connection establishment take several minutes #3252
    support
    Keymaster

    Hi,

    That should not normally happen. Typically the connection with Raspberry Pi takes less than 10 seconds.
    Please try the following to diagnose it:
    1. See if your Raspberry Pi CPU is busy doing something else by running the top command.
    2. Try addressing it by IP instead of hostname. Does that change anything?
    3. Try using Wireshark to see what happens on the network. Is all the time consumed waiting for one packet or are there several packets exchanged in between? Does with the SSH packets, or are there some suspicious ICMP packets in between?

    in reply to: Fail to Launch GDB Session #3227
    support
    Keymaster

    Hi,

    Sorry, have not received your settings screenshot yet. BTW, we have released VisualKernel 1.1 that supports debugging kernel over network. Let us know if that works for you better.

    in reply to: Add new libraries to C project in Visual Studio 2012 #3260
    support
    Keymaster

    Yes, this is correct. You need to specify the library name without the extension and the ‘lib’ prefix. E.g. just ‘pthread’ for libpthread.a. This comes from the syntax of gcc’s -l command that searches for the libraries automatically using the short library names. And as the linking happens on the Windows machine, the libraries should be present there (i.e. copied during sysroot synchronization).

    in reply to: Linux embedded Quick debug don’t work #3261
    support
    Keymaster

    Hi,

    The problem happens when VisualGDB runs a temporary script that is supposed to return the Pseudo-TTY name and instead gets something that does not look like a device path. This happens because your SSHD server tries to run some commands just before executing our script. I.e. some of the initialization scripts contain a reference to /usr/bin/X11/xauth, but the file is missing due to some reason.
    Note that when you connect with PuTTY, it uses the SSH shell mode, not the SSH command mode, that uses slightly different initialization scripts. Please try looking up what file could be referring to xauth and why it is missing.

    in reply to: two quick questions #3237
    support
    Keymaster

    Hi,

    We don’t invest into supporting Atmel devices because they have their own Visual Studio-based IDE (Atmel Studio). If there are third-party tools supporting DragonLink with GDB (i.e. implementing gdbserver), you could easily plug them in. Let us know if you need more details.

    You can always upgrade VisualGDB to a higher edition. However, the upgrade price depends on the time of upgrade. E.g. if you upgrade within the first month it’s just the price difference and if you want upgrade after the support/update year ends, you would need to pay the full price again.

    support
    Keymaster

    Hi,

    Unfortunately the GCC compiler does not emit enough information about defines to parse them during debugging. However, VisualGDB has a separate mechanism of tracking peripheral register names and replacing them with the corresponding expressions in the Watch window. If your register is not recognized, you can try editing the device definition files in %LOCALAPPDATA%VisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32devices (you can unzip the xml.gz file and just keep the .xml one, VisualGDB will use it automatically).

    in reply to: Fail to Launch GDB Session #3221
    support
    Keymaster

    Hi,

    Could you please check your virtual COM port settings on the virtual machine? Does the COM port number there match the number in VisualKernel settings? Could you please attach the screenshots of both COM port settings dialog and the VisualKernel debug settings dialog?

    BTW, if you are using VMWare, it is recommended to use VMWare GDB stub (http://sysprogs.com/VisualKernel/tutorials/vmware/) instead of a virtual COM port, as it’s much faster and more reliable.

    in reply to: Precompile settings #3210
    support
    Keymaster

    Hi,

    The easiest way to have a pre-build action without using the custom edition features would be to change the make command to run a bat file that first runs your custom command line and then invokes GNU make. It is not as convenient as the pre-build action list, but may work for some basic scenarios.

    in reply to: IntelliSense: wnsock2.h #3214
    support
    Keymaster

    Hi,

    Could you determine which include file causes this? Does it still happen on a default “hello, world” project? Could you share a screenshot of your IntelliSense settings page of VisualGDB Project Properties?

    in reply to: Precompile settings #3207
    support
    Keymaster

    Hi,

    Do you mean the pre-build steps in VisualGDB Project Properties? They are only available in Custom and Ultimate editions. If you were using a trial before and then bought a lower edition, the options would go away after the trial expires.

Viewing 15 posts - 7,186 through 7,200 (of 7,847 total)