support

Forum Replies Created

Viewing 15 posts - 7,081 through 7,095 (of 7,632 total)
  • Author
    Posts
  • in reply to: Debug inline function from include file #2773
    support
    Keymaster

    Hi,

    This is the limitation of the manual shared folder mode. You can overcome it by switching to the “shared windows folder mode”.
    Simply select “Use a shared Windows folder” in the Project Properties, click “Provide information required to mount the local folder” and select your shared Windows folder and the Linux mount point.
    This will provide enough information for VisualGDB to know which directories are part of the shared folder and which are not and thus need to be downloaded.

    E.g. if you mapped e:projects to /mnt/projects, VisualGDB will open files in /mnt/projects/my_project as well as in /mnt/projects/some_other_project directly, as it will know that all files under /mnt/projects are a part of the Windows share.

    in reply to: Problems to config Beaglebone black with QT #2797
    support
    Keymaster

    Hi,

    This can be an indication of missing tools or a problem in your QT configuration. If you click ‘ignore’ is the project created? Do you encounter any problems while building or debugging it?

    in reply to: VGDB1000 error #2765
    support
    Keymaster

    Just FYI: we have patched our STM32 linker scripts to include this fix. You can re-download the STM32 package from the Wizard to get the new fixed scripts.

    in reply to: No debug info on C-style unnamed structures #2776
    support
    Keymaster

    Hi,

    We have looked into it and added a workaround to VisualGDB 4.1r7. Please note that you can also resolve this issue by updating your GDB to 7.6.

    in reply to: Configure VisualGDB Remote source cache #2713
    support
    Keymaster

    We have fixed it in VisualGDB 4.1r7. Thanks for reporting this issue.

    in reply to: VisualGDB with VS2010 and STL containers #2760
    support
    Keymaster

    We have sent you the source code for the STLTypeVisualizers. If you encounter any issues with it, please let us know.
    Regarding octal display, GDB sometimes uses it internally, but we usually convert the values to either decimal or hexadecimal form. If you encounter octal output in some cases, please provide us with repro steps so that we could investigate and fix it.

    in reply to: IntelliSense error with __null #2749
    support
    Keymaster

    The compilation and IntelliSense use two independent source parsing mechanisms, so it could happen that IntelliSense shows false positive errors when its mechanism runs out of sync with the build mechanism.
    Regarding svc_uif.h file, is C:UsersUporabnikAppDataLocalVisualGDBRemoteSourceCache192.168.3.207005include referenced in Include Search Path (Visual Studio Project Properties -> NMake -> Include Search Path)?

    If __STDC__ is not present in the .h file, this can be happening because GCC does not report it when being tested with your configuration settings. This can be specific to your GCC version or some settings. The easiest workaround would be to create a new file (e.g. called gccfix.h), add it to ‘forced includes’ in Visual Studio Project Properties -> NMake and add the following code to it:

    #ifdef _MSC_VER
    #define __STDC__
    #endif

    This should provide IntelliSense with the missing definitions. _MSC_VER is a macro that is defined by Microsoft Compiler (and Microsoft IntelliSense engine) and won’t be present during build with GCC.

    in reply to: IntelliSense error with __null #2747
    support
    Keymaster

    This is strange. __STDC__ should be defined in a gcc_Debug.h file in your project directory and this file should be added to ‘forced includes’ in Visual Studio project properties. Could you please recheck whether the file contains the __STDC__ and whether it’s parsed by IntelliSense?

    in reply to: VisualGDB with VS2010 and STL containers #2756
    support
    Keymaster

    The structure of the STL containers can be different in your toolchain. Please go to the GDB Session pane, select “Raw GDB Output”, add your vector to the Watch window, expand it and send us the contents of the GDB Session window. It will contain GDB commands issued by VisualGDB that should explain why STL vector visualization is not working.

    in reply to: OpenCV Qt Linker error #2768
    support
    Keymaster

    Please try surrounding the library list with -Wl,–start-group and -Wl,–end-group. Note that our latest Raspberry toolchain contains the fix that eliminates the need to specify full path for libraries. You can now simply mention them in the LIBRARY_NAMES; dependent libraries will be included automatically. To use this feature you will need to download the latest version of the Raspberry toolchain.

    support
    Keymaster

    Hi,

    We have tried to reproduce your problem on our side, but could not. Could you please share the exact bashrc file you have and the error you are getting? Does it happen with stand-alone SmarTTY or only with the one embedded in VisualGDB?

    in reply to: flashing offset during debugging #2753
    support
    Keymaster

    Hi,

    Yes, you can make a workaround. First of all, if you are flashing your program using the bootloader (or any other way that ensures correct FLASH layout), you can simply disable “program FLASH memory” checkbox in VisualGDB Project Properties and VisualGDB won’t touch the contents of your FLASH memory.

    Alternatively you can get your bootloader code included into the resulting ELF file during build. This can be accomplished by declaring an array containing your bootloader code, placing it into a separate section and modifying the linker script to put this section at the beginning of the FLASH. I.e. you will first need to generate a file like this from your bootloader image (.bin file, not the .elf file):

    __attribute__((section(".bootloader"))) char test[] = {0x01, 0x02, ...};

    Then you need to change the linker script to put the .bootloader section before anything else:

    SECTIONS
    {
    .bootloader :
    {
    . = ALIGN(4);
    KEEP(*(.bootloader))
    FILL(0xff)
    . = 65K;
    } > FLASH
    ...
    }

    Please double-check everything by reading the .map file (or looking at the generated .bin file).

    P.S. The FLASH Security bits mentioned in the previous post are used by Freescale Kinetis devices, so you don’t need to worry about them if you are using STM32.

    in reply to: flashing offset during debugging #2751
    support
    Keymaster

    Yes, it is possible to configure VisualGDB to place your code starting at a different address. Please see this thread for an example: viewtopic.php?f=5&t=2777
    Note that if you are using Freescale Kinetis, the FLASH region at addresses 0x400-0x410 should contain FLASH security bits. If you change your linker script, ensure that the security bits end up in the same place.
    Please also note that if you program your project starting at 64KB using VisualGDB, it will fill the first 64KB with zeroes and not just keep them unchanged.

    in reply to: STM32F4 discovery printf to VS output window #2731
    support
    Keymaster

    Currently this scenario is not directly supported, although we plan to add it in one of the next releases.
    As a workaround you can use any third-party command-line tool that will display the data coming from a virtual COM port and set VisualGDB to show its output when your program is running. E.g. if your device is connected to a virtual COM port available as COM4, go to VisualGDB Project Properties, Custom Debug Steps page, select “Use the following command to start the console” and specify the following parameters:
    Command: cmd
    Arguments: /c type COM4

    If your board does not include an external virtual COM port chip (e.g. FTD2xx), you will need to use the USB library on the STM32 device to implement one using the STM32 USB interface. Please refer to STM32 examples for a sample Virtual COM port project.

    in reply to: using VisualGDB with sqlite3 #2689
    support
    Keymaster

    In order to link correctly with the sqlite libraries the file called libsqlite3.so should be present in one of the library directories. You can search for it by running the following command:

    cd /usr/lib
    find . | grep sqlite3

    The expected output would be something like this:

    ./i386-linux-gnu/libsqlite3.so.0
    ./i386-linux-gnu/libsqlite3.so.0.8.6
    ./i386-linux-gnu/pkgconfig/sqlite3.pc
    ./i386-linux-gnu/libsqlite3.so
    ./i386-linux-gnu/libsqlite3.a
    ./i386-linux-gnu/libsqlite3.la

    If all the files are present, but the linker does not find them, please double-check your settings and try restarting the Linux machine. If the problem persists please try creating a simple .c file containing a main() function and build it with the libsqlite library using command line:

    gcc file.c -lsqlite3

    If you get the same error, please add the -v option to enable the verbose mode and provide us with the gcc output. If command-line compilation works, please compare the basic command line with the command line mentioned in VisualGDB build output.

Viewing 15 posts - 7,081 through 7,095 (of 7,632 total)