Saturday, December 16th 2017, 12:28am UTC+1

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

SuperGian78

Beginner

Date of registration: Jun 20th 2010

Posts: 7

1

Wednesday, March 30th 2011, 9:26pm

[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 <http://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:
<https://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
SuperGian78 has attached the following file:
  • redboot.zip (116.5 kB - 834 times downloaded - Last download: Yesterday, 8:29am)

SuperGian78

Beginner

Date of registration: Jun 20th 2010

Posts: 7

2

Friday, April 1st 2011, 3:25pm

News ?

Someone from SEGGER have news? Are you informed about this problem or is something wrong in my procedure?

best regards Gian

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,514

3

Monday, April 4th 2011, 9:33am

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

SuperGian78

Beginner

Date of registration: Jun 20th 2010

Posts: 7

4

Monday, April 4th 2011, 11:58am

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

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

robert

Beginner

Date of registration: Apr 4th 2011

Posts: 7

5

Tuesday, April 5th 2011, 9:06am

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

robert

Beginner

Date of registration: Apr 4th 2011

Posts: 7

6

Wednesday, April 6th 2011, 7:16am

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

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,514

7

Wednesday, April 6th 2011, 4:32pm

Hi Robert,

thanks for the input.

Quoted

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

robert

Beginner

Date of registration: Apr 4th 2011

Posts: 7

8

Wednesday, April 6th 2011, 10:37pm

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

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,514

9

Thursday, April 7th 2011, 9:14am

Hi Robert,

Quoted

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:

Quoted

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

robert

Beginner

Date of registration: Apr 4th 2011

Posts: 7

10

Thursday, April 7th 2011, 10:31am

upsla

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

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,514

11

Thursday, April 7th 2011, 7:20pm

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

robert

Beginner

Date of registration: Apr 4th 2011

Posts: 7

12

Thursday, April 7th 2011, 8:59pm

i am happy to do so.

regards robert
robert has attached the following file:
  • maple_native.zip (259.91 kB - 927 times downloaded - Last download: Dec 6th 2017, 3:01pm)

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,514

13

Friday, April 8th 2011, 9:25am

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

robert

Beginner

Date of registration: Apr 4th 2011

Posts: 7

14

Friday, April 8th 2011, 10:06am

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

SuperGian78

Beginner

Date of registration: Jun 20th 2010

Posts: 7

15

Monday, April 18th 2011, 2:54pm

Is there some news about my original problem? Will I wait for your update of for a CodeSourcery update?

Best regards Gian.

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,514

16

Thursday, April 21st 2011, 9:49am

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

SuperGian78

Beginner

Date of registration: Jun 20th 2010

Posts: 7

17

Thursday, April 21st 2011, 9:19pm

Thank You very much Alex.

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,514

18

Tuesday, April 26th 2011, 8:36am

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

robert

Beginner

Date of registration: Apr 4th 2011

Posts: 7

19

Wednesday, April 27th 2011, 3:49pm

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

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,514

20

Thursday, May 26th 2011, 5:00pm

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