support

Forum Replies Created

Viewing 15 posts - 7,006 through 7,020 (of 7,512 total)
  • Author
    Posts
  • in reply to: Debugging problems #2454
    support
    Keymaster

    Hi,

    This still looks like an incompatibility between your programmer and the msp430.dll. It is a known issue for Olimex devices (e.g. see https://forum.sparkfun.com/viewtopic.php?t=13349).
    Please try copying ALL dlls from the Olimex directory (also hil.dll) into the msp430 bin directory. If this does not help, please also contact Olimex support asking whether your programmer supports debugging at all and whether it needs a firmware update. Please also inquire whether they provide a GDB server.

    The download errors can be caused by various factors (e.g. what is the size of the BIN file?) but should not be related to the “Device not found” bug as device detection happens before downloading the firmware.

    in reply to: How can I do the following…? #2435
    support
    Keymaster

    Hi,

    Thanks for the suggestions, we have added them to our feature plan. For now you can use the following workarounds:
    1. To disable an action from a command list you can press the “Copy” button, paste it into a text editor (it will be pasted as XML) and delete it. To get it back simply copy the XML definition back to clipboard and use the “Paste” button.
    2. Try using Visual Studio macros to script commonly used commands. You can execute VisualGDB.exe /build file.vgdbsettings to let it run build commands from a given .vgdbsettings file.

    We will share a link to the pre-release build in a couple of weeks, but please note that the .vgdbsettings file format has changed significantly and your files will be upgraded when you edit them with the new VisualGDB. To be able to use them with the old version, you will need to backup them.

    As for the environment variables in the SSH manager, they may not work out of the box. Please let us know what you are trying to achieve so that we can provide a solution.

    in reply to: How can I do the following…? #2433
    support
    Keymaster

    Hi,

    A bit of clarification regarding the file transfer. VisualGDB actually maintains a local source cache as well. After transferring the source files it remembers the file names and their modification times in VisualGDBCacheSourceCache.dat and uses it during subsequent builds to determine which files have changed. VisualGDB uses the .Net BinaryFormatter to maintain the cache file, so normally it takes less than a seconds to update the cache. Note that VisualGDB does this for all files in the directory specified in the project settings. You could reduce the time greatly by specifying your working subdirectory instead of the root project directory. Alternatively you could setup shared folders (see this tutorial: http://visualgdb.com/tutorials/linux/ImageMagick/) to avoid file transfers completely.

    Having an option to skip build command if no source files have been changed is a good suggestion, we will add this to the upcoming release.

    Regarding the custom variables, you can currently use the environment variables to do per-user tweaking and refer to those as $(VariableName) in your VisualGDB settings. We have also added a much better support for configurable per-user variables in the upcoming release based on the feedback from other customers (supporting host names, user names, etc), however this will be a major release redefining the usability of GCC settings editing, so it will take 1-2 months before it is out. We could also provide you with a pre-release build once it reaches the point when it passes our standard test scenarios 🙂

    P.S. If you are dealing with huge projects with custom types and have C# knowledge, you may be interested in our type visualizer SDK that can be used to let VisualGDB display arbitrary user-defined types in a readable way. You can find out more about it in this tutorial: http://visualgdb.com/SDK/tutorials/SimpleArrayVisualizer/

    in reply to: raspberry pi questions #2430
    support
    Keymaster

    Hi,

    Yes, running as root is required to access low-level hardware functionality. This is by design.
    The easiest way to develop GUI for Raspberry PI with VisualGDB would be with QT. Please follow this tutorial: http://visualgdb.com/tutorials/linux/qt/

    Unfortunately VisualGDB does not support Visual Basic, as the main focus of our product is to provide Windows-style experience with native Linux tools and Linux has no native support for Visual Basic.

    in reply to: Not connecting to gdbserver #2428
    support
    Keymaster

    Hi,

    This can be caused by version incompatibility between gdbserver and your device.
    Does the problem also happen on the Emulator or other devices with more recent Android versions?
    If you are using an old phone version, please try using an older NDK version. If this helps, you can replace the prebuilt gdbserver in the new NDK with the one from the old NDK.

    in reply to: Building and debugging cmake app #2323
    support
    Keymaster

    Could you paste a typical build log showing the problem here? Looks like cmake uses a different format for “entering directory”/”leaving directory” messages and this confuses VisualGDB.

    in reply to: Debugging is very flaky – any ideas? #2027
    support
    Keymaster

    Hi,

    First of all, GDB performance is not related to the files inside the Solution Explorer in Visual Studio – they are handled by different mechanisms. Here is how the debugging information gets into GDB:
    1. When you compile your project (either launching make directly or letting VisualGDB do it) each .c/.cpp file gets translated to an .o file containing the compiled code and the debugging info (references to source lines in source files for each function). For VisualGDB this happens ‘behind the scenes’ and VisualGDB has no direct control over it.
    2. When you link your final executable, the GNU linker merges the debugging information from all .o files and puts it into the final executable file. VisualGDB does not control this directly either.
    3. When you start your debugging session with VisualGDB, it runs gdb which in turn reads the debugging information from the executable file (that contains debugging sections from all .o files merged together).

    The problem you are describing can have one of two reasons:
    1. GDB itself has difficulties dealing with the huge amount of debugging information inside the executable file.
    2. VisualGDB issues some commands to GDB that cause great delays.

    In order to diagnose this further please use the GDB Session window in Visual Studio. Select the “All GDB Interaction” mode to see the commands that VisualGDB sends to GDB automatically. Before stepping into a function that usually hangs clear the GDB Session window and observe the commands that get executed afterwards. If GDB does not report the “*stopped” message for a long time, then the delays are caused by GDB itself. If it reports “*stopped” quickly, but then gets delayed while handling some command from VisualGDB, please let us know which command causes the delay.

    Both cases can be solved: VisualGDB can be configured in many ways to disable certain commands (disabling some secondary features). If the cause is the poor performance of GDB itself, you can use the ‘strip’ command to remove the debug information from the object files that you do not intend to debug before you do the linking. This would reduce the size of debugging information and make GDB perform faster at a cost of not being able to debug the ‘stripped’ source files until they are recompiled again.

    in reply to: Importing a very large project – Help!! #2070
    support
    Keymaster

    Hi,

    What you are describing looks like a limitation of Visual Studio. Adding and indexing lots of files may take a great deal of time. You can improve this by only adding the files you want to work with.

    When you are importing a project using existing makefiles, you can select “Do not import sources to Solution Explorer” on the “Source Code Location” page. VisualGDB will not add any files to Solution Explorer, but building and debugging will work nonetheless. In order to make IntelliSense work you will need to add the files you are going to edit manually and specify include paths in VisualGDB settings.

    As you are using existing makefiles, there the files in Solution Explorer are handled separately from the files participating in build, as the build is fully handled by your makefile system without any interference from VisualGDB. When you start debugging, VisualGDB will get the list of files from the symbols produced by the build system using a different mechanism that should not reduce the performance.

    Please let us know if you need further help.

    in reply to: Public/private key SSH authentication #2126
    support
    Keymaster

    It looks like the converted private key has invalid format. Please try generating a keypair using OpenSSH tools (e.g. from cygwin package or directly on Linux) and use the file generated by it.
    If that works, please compare the format of that key and the key you have tried before.

    in reply to: Public/private key SSH authentication #2127
    support
    Keymaster

    Hi,

    You are correct about private and public keys. VisualGDB mentions the public key as the term that describes the authentication process is “public key authentication”. We will consider making the wording less confusing here.
    If you have already setup the public key authentication with PuTTY, you need to convert its key to the OpenSSH format and specify it in the “OpenSSH key from file” field.

    It would be easier, however, to select “Password” and enable “Setup public key authentication”. VisualGDB will authenticate for the first time using the password, generate and save the keys, add the public key to the key list on the server and use the private key for authentication from now on.

    in reply to: how to co work with valgrind? #2058
    support
    Keymaster

    Hi,

    We have investigated your problem and found a bug in VisualGDB. When running the gdbserver command VisualGDB always tries to use the deployment machine which is not set in your case.
    We will fix this in the next release. As a workaround please enable the “Deploy executable on a different machine” checkbox in the VisualGDB Project Properties and specify the same machine as the deployment machine.

    If you get ‘broken pipe’ messages please ensure that no other valgrind instances are running in the background.

    in reply to: beginners problems/mistakes #2206
    support
    Keymaster

    Hi,

    Please try disabling the inline building. Click Tools->Options, select VisualGDB->General and set “Enable Inline Project Builder” to “False”.

    in reply to: Application output #2222
    support
    Keymaster

    Hi,

    Are you talking about Linux or Windows projects? For Windows it’s not supported, on Linux you need to update to VisualGDB 3.1 to see the output.

    in reply to: beginners problems/mistakes #2202
    support
    Keymaster

    Hi,

    VisualGDB sets the GCC language to English by setting the LANG environment variable to en_US.UTF8. Looks like some settings on your computer override this and cause the messages to appear in German.
    Please try adding the following lines to your ~/.profile file:
    export LANG=en_US.UTF8
    export LANGUAGE=en_US:en

    After modifying the file please restart your Linux machine and try running the wizard again.

    in reply to: beginners problems/mistakes #2204
    support
    Keymaster

    Hi,

    It looks like you have changed the locale for one SSH window only. When VisualGDB opens anther SSH channel, the locale is still German. Please modify the global setting instead.
    Please refer to the documentation of your Linux distro for details on changing the default locale for a user.

Viewing 15 posts - 7,006 through 7,020 (of 7,512 total)