support

Forum Replies Created

Viewing 15 posts - 6,646 through 6,660 (of 7,813 total)
  • Author
    Posts
  • in reply to: Moved: Reply To: VisualGDB support #7299
    support
    Keymaster

    Hi,

    You can use VisualGDB to develop C/C++ applications for Beaglebone. VisualGDB uses SSH to build and debug your code.

    You can build it either directly on the Beaglebone or by using a cross-compiler provided by us. We recommend starting by following our BeagleBone tutorial.

    You can make any application type that is based on C/C++, e.g. Qt-based ones.

    in reply to: Debugging only with gdbserver #7297
    support
    Keymaster

    Hi,

    When you are not using gdbserver, VisualGDB opens a separate SSH console within the main SSH session and redirects your program output to that console using the ‘tty’ command in GDB. Perhaps something about this mechanism is broken? You can see the tty name by switching the GDB Session window to the “All GDB Interaction” mode. Can you reproduce the problem on a clean “Hello, World” project for the same target?

    in reply to: VisualGDB: Cannot parse project file #7293
    support
    Keymaster

    Hi,

    VisualGDB parses this file to build a list of all source files in your project and synchronize it with the Makefile.

    Please send us the file using our support ticket system so that we could see why it is not being parsed.

    in reply to: VisualGDB with own build chain (make) #7292
    support
    Keymaster

    No problem.

    in reply to: Nordic nrf51xxx Hardfault on SystemInit() #7291
    support
    Keymaster

    Hi,

    Do you have the “Reset device after programming” flag enabled in the Debug Settings as described in the tutorial?

    in reply to: Unexpected reply from ESP8266 #7283
    support
    Keymaster

    Hi,

    Please try running the bootloader test program from here.

    Run BootloaderTest <COM port> 74880.

    Does it report a successful sync? If not, what exact output does it show? Can you double-check that the state of GPIO0, GPIO2 and GPIO15 boots your board into the UART download mode as described here?

    in reply to: Raspicam example not working #7282
    support
    Keymaster

    Hi,

    The “EXEC : CMake error : cmake_symlink_library: System Error: No error” looks very strange. Please try using a newer version of CMake.

    If this does not help, please try running it on a different machine.

    in reply to: Nordic nrf51xxx Hardfault on SystemInit() #7281
    support
    Keymaster

    Hi,

    That usually happens when the stack pointer points to an invalid location. Please double-check your MCU type. You can also try using the Memory window to edit the memory at the $sp address to see if the memory there is writable. If you find out that it’s not writable, please change the MCU type to a one with a smaller RAM.

    in reply to: VisualGDB not flashing device #7277
    support
    Keymaster

    Hi,

    We would recommend checking device compatibility with Segger support. Their software is usually pretty reliable, so it might be a good investment to get a J-Link.

    in reply to: VisualGDB with own build chain (make) #7273
    support
    Keymaster

    Hi,

    You can try the following:

    • Create a new VisualGDB project
    • Copy and rename the <Project>-<Configuration>.vgdbsettings file to the new project
    • Select the .vgdbsettings file as the primary output of your project via Visual Studio project properties
    • Open VisualGDB Project Properties for the new project and adjust your settings

    As long as the .vgdbsettings file is set as the primary project output, once you press F5, VisualGDB will automatically engage and use the settings from the .vgdbsettings file to start debugging.

     

    in reply to: VisualGDB not flashing device #7272
    support
    Keymaster

    Hi,

    If the flashing is broken when you use the GDB from your toolchain, but works with our GDB, this looks like a bug in your GDB executable. You can simply replace it with the gdb from SysGCC.

    You can also add the OpenOCD flashing command to the startup commands in the VisualGDB Project Properties window. This should invoke the programming automatically.

    The error message is shown because you have used all the hardware breakpoints on your device. You can work around this using one of the following methods:

    • Place some of the code or the entire program into RAM so that the software breakpoints will work
    • Do not use more than 4 breakpoints at the same time
    • Use Segger J-Link with Segger software that supports unlimited software breakpoints in FLASH (please confirm the specific versions and device compatibility with Segger)
    in reply to: VisualGDB not flashing device #7262
    support
    Keymaster

    Hi,

    This is very strange. Please try using the OpenOCD’s FLASH programming commands instead of the GDB ones.

    You can issue them from the GDB Session window by prefixing them with “mon”, e.g. “mon program c:/project.elf verify”. If it does not work with the ELF files, would it work with the BIN files?

    in reply to: VisualGDB with own build chain (make) #7261
    support
    Keymaster

    Hi,

    You can do it in 2 different ways:

    • Select “Specify the toolchain manually” in the project wizard. VisualGDB will try to guess the right parameters for your toolchain and setup a Makefile for you.
    • Use the Custom project wizard to just specify the build command line. VisualGDB will run it “as is” and won’t ask for anything else.
    in reply to: VisualGDB not flashing device #7255
    support
    Keymaster

    Hi,

    Yes, the addresses look normal. The .bss section contains uninitialized variables, so it does not have the LOAD attribute by design.

    Then the problem is either in the faulty hardware or in your OpenOCD settings. Please try creating a new project for the same chip using default settings and programming it. Does this work?

    If yes, please replace the ELF file of the project that is broken with the ELF file from the project that works. Then run the project without rebuilding it (Debug->Start debugging with GDB). Does VisualGDB load the other project file using the current project settings correctly? Does compare-sections succeed? If no, what is different between the 2 projects’ settings. If yes, what is different between the 2 ELF files (you can enable the .map file generation to dump a general overview of the ELF file structure during building)?

    in reply to: VisualGDB not flashing device #7252
    support
    Keymaster

    Hi,

    Based on a quick look, you are using a custom linker script, so the problem might be inside it.

    Please use the GDB Session window to run the following commands:

    • compare-sections
    • maint info sections

    The first command will compare each section of the ELF file (e.g. code, data, interrupt handlers) to the memory contents on the device and will pinpoint the mismatching ones.

    The second command will list all sections in the ELF file. Please check that each section marked with the LOAD attribute is within your device FLASH or RAM bounds, e.g.:

     [1]     0x0400->0x092c at 0x00008400: .text ALLOC LOAD READONLY CODE HAS_CONTENTS

    Section size = 0x92c – 0x400 = 0x52C, range = 0x8400 – 0x892C => within FLASH range (0x0000 – 0xFFFF). The RAM and FLASH addresses and sizes can be found in your device datasheet.

    If this does not help solve the problem, please let us know the exact device you are using and attach the output of both commands.

    Note that sections like .debug_info do not have the LOAD attribute and hence do not need to be checked as they are not loaded into the device.

Viewing 15 posts - 6,646 through 6,660 (of 7,813 total)