[SOLVED]Remote 'g' packet reply is too long with "SEGGER J-Link GDB Server V4.25g (beta)" and "CodeSourcery G++ Lite 2010.09-51"

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED]Remote 'g' packet reply is too long with "SEGGER J-Link GDB Server V4.25g (beta)" and "CodeSourcery G++ Lite 2010.09-51"

    I try to debug a STM32F107VC Cortex M3 with GDB and my J-Link interface HW version 5.3.
    The toolchain version is "Sourcery G++ Lite 2010.09-51" and "SEGGER J-Link GDB Server V4.25g (beta)" under Windows 7 Ultimate x64 and I have the following error:

    C:\Program Files (x86)\CodeSourcery\Sourcery G++ Lite\bin>arm-none-eabi-gdb.exe
    GNU gdb (Sourcery G++ Lite 2010.09-51) 7.2.50.20100908-cvs
    Copyright (C) 2010 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "--host=i686-mingw32 --target=arm-none-eabi".
    For bug reporting instructions, please see:
    <support.codesourcery.com/GNUToolchain/>.
    0x00000000 in ?? ()
    Target endianess set to "little endian"
    Select auto JTAG speed (1000 kHz)
    Resetting target
    Sleep 100ms
    .gdbinit:21: Error in sourced command file:
    Remote 'g' packet reply is too long: 000000202500000808ed00e0000000205d470008410
    000003b000000330100207a422009a41249ae289ae8b41d7029e8e700000800000120ffffffffb41
    d0008000000000000000000000000000000000000000000000000000000000000000000000000000
    00000000000000000000000000000000000000000000000000000000000000000000000000000000
    00000000000000000000000000000000000000000000000000001

    I use .gdbinit and the script is the following:

    # connect to the J-Link gdb server
    target remote localhost:2331
    # Set gdb server to little endian
    monitor endian little
    # Set JTAG speed in khz
    monitor speed auto
    # Reset the target
    monitor reset
    monitor sleep 100
    #Open the ELF file with symbols
    file "C:\\Users\\Mr32Bit\\Desktop\\Demo\\untitled_install\\bin\\redboot.elf"
    # Vector table placed in ROM
    monitor writeu32 0xE000ED08 = 0x08000000
    #Init registers
    monitor reg sp = (0x08000000)
    monitor reg pc = (0x08000004)

    In attach there is my ELF file

    Best regards Gian
    Files
    • redboot.zip

      (116.5 kB, downloaded 1,220 times, last: )
  • Hello Gian,

    so far we got a sample project from a customer which shows the problem.
    It has not been analyzed so far what is causing this problem.
    But it does only occur under special circumstances because
    we have also tested some other sample projects / sample ELF files for Cortex-M which do not show this problem.


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • This weekend I have test the same ELF file with CodeSourcery Linux edition and my Windows 7 Ultimate as GDB server and I have the same problem. The problem is coming only after I have load the ELF file otherwise no problem.
    If you need I can make mor tests for you. Ask me what you need. In this condition I'm not able to debug my project.

    Best regards Gian

    SEGGER - Alex wrote:

    Hello Gian,

    so far we got a sample project from a customer which shows the problem.
    It has not been analyzed so far what is causing this problem.
    But it does only occur under special circumstances because
    we have also tested some other sample projects / sample ELF files for Cortex-M which do not show this problem.


    Best regards
    Alex
  • hi,
    i am using a stm32f103vet6 - and you can quess it.
    i have the same problem.
    i tried different commands and setups - nu luck up to now.
    last we year we did use 4.10 and 4.14i with success programming a stm32w103.
    but i don't know how to go back from the firmware update which did come with 4.24g.

    robert
  • codesourcery

    ok,
    i switched over to a olimex jtag and encountered the same issue the the packet beeing to long.
    switching back to an the previous version of codesourcery did solve the problem parially.
    i can programm a stm32f103vet6 device but no success when debugging.
    to do so i had to kill previously allocated gdb instances.
    is there a config entry to er-use already running gdb instances?
    robert
  • Hi Robert,

    thanks for the input.

    i switched over to a olimex jtag and encountered the same issue the the packet beeing to long.
    switching back to an the previous version of codesourcery did solve the problem parially.


    Sounds like this is no SEGGER GDB Server specific problem.
    We already got in contact with CodeSourcery in order to identify the root cause of the problem.
    Wherever the problem is (on our side or on their side): It will be fixed as soon as it has been located.


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • one step hurther

    hello alex,



    SEGGER J-Link GDB Server V4.25g (beta)

    JLinkARM.dll V4.25g (DLL compiled Mar 29 2011 15:04:28)

    Listening on TCP/IP port 2331

    J-Link connected
    Firmware: J-Link ARM Lite V8 compiled Jan 31 2011 18:38:46
    Hardware: V8.00
    S/N: 228001252
    WARNING: CPU core not found.

    J-Link found 0 JTAG device, Total IRLen = 0
    JTAG ID: 0x00000000 (ARM9)

    Free mode: To be used for non-commercial and evaluation purposes only.

    Connected to 127.0.0.1
    Reading all registers
    Read 4 bytes @ address 0x00000000 (Data = 0xABABABAB)
    Select SWD as target interface
    Select auto JTAG speed (2000 kHz)
    Target endianess set to "little endian"
    Select flash device: STM32F103VE
    Flash breakpoints enabled
    Flash download enabled
    Downloading 16112 bytes @ address 0x08000000
    Downloading 16160 bytes @ address 0x08003EF0
    Downloading 3616 bytes @ address 0x08007E10
    Downloading 8 bytes @ address 0x08008C30
    Downloading 2264 bytes @ address 0x08008C38
    Writing register (PC = 0x0800849C)
    ERROR: Failed to prepare for programming.
    Readback during RAM check failed at offset 0x1104: Expected 15, Found 93.
    Please check your flash settings!
    Connection to debugger closed !


    i can program the device but the flash settigns are wrong

    my gdbinit looks like:

    set mem inaccessible-by-default off

    target remote localhost:2331

    monitor interface SWD

    monitor speed Auto

    monitor endian little

    monitor flash device = STM32F103VE

    monitor flash breakpoints = 1

    monitor flash download = 1


    load build/maple_native.elf


    monitor reg r13 = (0x00000000)

    monitor reg pc = (0x00000004)

    monitor reset

    continue



    i have no idea what's the cause.

    regards

    robert
  • Hi Robert,

    i can program the device but the flash settigns are wrong


    Not sure if I understand your problem.
    According to the error message you posted:
    ERROR: Failed to prepare for programming. Readback during RAM check failed at offset 0x1104: Expected 15, Found 93.


    flash can not be programmed. You wrote that you can program the flash but the flash settings are wrong.
    What exactly do you mean with that?


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • hello,
    what i tried is to download the program into the internal flash memory.
    some bytes have been written but then the verify fails.
    this is my understanding.

    the device itself is a stm32f103vet6

    regards
    robert
  • Hi Robert,

    could you please also post the ELF file, so we can try to reproduce this here?
    We do not have a STM32F103VE here, but a 103ZE should also do it.


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Robert,

    so far I do not see any problems when downloading the ELF file to flash using the GDB Server.
    Everything works fine so far.


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • hmmm, i am using a standard installation of eclipse and the gnuarm plugin.
    installing the segger sw is a matter of running the installation app.
    do not 'see' what could cause the problem.

    i will switch my development pc ... maybe i can reproduce the problem.
    or it works :)

    thanks for your help.
    robert
  • Hi all,

    We do not have a final confirmation but it seems to be a problem with the Sourcery G++ Lite version.
    They are working on this. A new version of Sourcery G++ Lite is planned soon.


    - Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi all,

    now we have a final confirmation from CodeCourcery.
    It is a problem in the Sourcery G++ Lite version. It is not a problem on the GDBServer side.

    It will be fixed in a new version of Sourcery G++.

    - Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Alex wrote:

    Hi all,

    now we have a final confirmation from CodeCourcery.
    It is a problem in the Sourcery G++ Lite version. It is not a problem on the GDBServer side.

    It will be fixed in a new version of Sourcery G++.

    - Alex
    hi alex,
    thank you very much for the information.
    now we need to wait for the 'new' version :)

    best regards
    robert
  • Hi all,

    did anyone tried arm-2011.03-42 so far?
    I hope to get a chance to give it a try withing the next days, but maybe someone here already checked it?


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.