Forum: Compiler & IDEs STM32 + CodeSourcery + Eclipse + JLink, Problem mit gdb


von peterguy (Gast)


Lesenswert?

Hallo,

ich versuche grade, meine STM32 Toolchain ans laufen zu bringen.
Die Toolchain besteht aus:
+ STM32-H103 Controllerboard von Olimex
+ JLink edu
+ Eclipse
+ CodeSourcery G++
+ FreeRTOS Beispielprojekt

Im Prinzip scheint alles zu funktionieren, also der GDB Server verbindet 
sich mit dem JLink, der Controller wird erkannt, das Projekt kompiliert.

Mein Problem liegt jetzt darin, daß ich beim Starten des Debugvorgangs 
die Fehlermeldung bekomme, die 'g' Paketlänge wäre falsch.

Die Fehlermeldung kommt sowohl in Eclipse, als auch in der Konsole, wenn 
ich den GDB manuell bediene.


Irgendjemand ne Idee was da schiefläuft?

Gruß,
Peter

von joh (Gast)


Lesenswert?

Ich nehme an, Du benutzt die neueste Codesourcery Version.

Versuch´s mal mit einer älteren. Kann mich nicht genau erinnern,
hatte aber ein mglw. ähnliches Prob mit dem (damals) neuesten 
Codesourcery gdb.

HDH,

joh

von Tecnologic (Gast)


Lesenswert?

Hi Peter,

Wie hast du den Segger gdb denn in Eclipse configuriert?

Start Comands usw. meine ich.

Poste mal deine Einstellungen des DBG Hardware debugings.

MfG

Tec

PS: habe Eclipse + Codesourcery +  J-Link EDU + STM3210B am laufen.

von peterguy (Gast)


Lesenswert?

@joh:
Ja, habe die neueste Version runtergeladen. Ich versuchs heut Abend mal 
mit ner älteren. Welche hast du denn bei dir am laufen?


@Tecnologic:
Ich such die Einstellungen heute Abend mal raus.
Sind aber aus dem Forum hier zusammenkopiert und sollten laut Aussage 
der Threadersteller so funktionieren.
Da du die Toolchain bei dir am Laufen hast, kannst du mir mal deine 
Versionsummern sagen? Also von CodeSourcery und gbd Server?


Ich habe zwischenzeitlich mal ein wenig gegoogelt, der 'g' Paket Error 
ist wohl auf gdb-Protokollprobleme zurückzuführen.
Das würde ja für die Theorie von joh sprechen.

von peterguy (Gast)


Lesenswert?

Hab mal nachgesehen:
Genaue Fehlermeldung:
Remote 'g' packet reply is too long: 
000000000000000000000000000000000000000000000000000000000000000000000000 
000000000000000000000000000000000000000000000000000000000000000000000000 
000000000000000000000000000000000000000000000000000000000000000000000000 
000000000000000000000000000000000000000000000000000000000000000000000000 
000000000000000000000000000000000000000001000000
Versionen:
CodeSourcery arm-none-eabi-gdb.exe: 7.2.50.20100908
SEGGER J-Link GDB Server: V4.24d

Konfiguration in Eclipse (Initialization):
set mem inaccessible-by-default off
target remote localhost:2331
monitor speed Auto
monitor endian little
monitor flash device = STM32F103RB
monitor flash breakpoints = 1
monitor flash download = 1

Run Commands:
monitor reg r13 = (0x00000000)
monitor reg pc = (0x00000004)
monitor reset
continue

von Jan (Gast)


Lesenswert?

Hallo Peterguy

Ich habe auch so meine Probleme mit dem Jlink GDB server.

In der Fehlermeldung die in der Console auftaucht steht vor dem Remote G 
Packet reply noch das Kommando bei dem der Fehler aufgetreten ist.
Schau nochmal das du den kompletten Log postest.

mfg Jan

von peterguy (Gast)


Lesenswert?

Laut gdb Referenz im Netz (Hab den Link leider nicht mehr) ist das Paket 
'g' für die Übermittlung der Registerdaten zuständig.

Habe übrigens mal eine ältere Version von CodeSourcery runtergeladen, 
nämlich 2010q1-188. Mit dieser kommt die Fehlermeldung nicht!

Der GDB Server hält die Verbindung jetzt auch, statt sie wie zuvor 
abzubrechen.
Bin aber zeitlich nicht dazugekommen weiter zu testen, das hole ich dann 
heut Abend nach

von Random .. (thorstendb) Benutzerseite


Lesenswert?


von Alex E. (tecnologic) Benutzerseite


Lesenswert?

HI,

Ich habe Segger 4.24d wie du drauf und Sourcery G++ Lite 2010.09-51
also das neuste, ich habe da auch erst vor ein paar Tagen neu gemacht.

Da ich gerade nicht an meinem Rechner bin in dem Thread habe ich mein
Template für Eclipse geposted, da müsste mein J-Link Konfig. drin sein.

Beitrag "Re: STM32 ST-Library Einstieg"


MfG

Tec

von chrysn (Gast)


Lesenswert?

Für das "Remote 'g' packet reply is too long"-Problem hab' ich ein 
Workaround gefunden: Das Problem scheint dadurch zu entstehen, dass gdb 
beim Laden der Datei die ARM-ABI von AAPCS auf APCS umstellt; erst ab 
dann kommen die Fehlermeldungen. Meine gdb-Konfigurationsdatei sieht so 
aus:
1
# gets set when loading the file, without this i get the "Remote 'g' packet
2
# reply is too long" errors
3
set arm abi AAPCS
4
5
target remote localhost:2331
6
monitor speed auto
7
# this seems to be less about the architecture and more about how to
8
# communicate with gdb. "set endian big" works just as well.
9
monitor endian little

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.