Forum: Mikrocontroller und Digitale Elektronik STM32: Debuggen mit J-Link in Eclipse vs. gdb command line


von U. E. (Gast)


Angehängte Dateien:

Lesenswert?

Hi,
als frischgebackener Besitzer eines J-Link (Edu) bin ich gerade dabei, 
ein einfaches "Blinking LED" Programm für den STM32F103 zu debuggen - 
oder besser gesagt, zu lernen wie das geht. Ich möchte in Eclipse 
debuggen- das klappt aber noch nicht, im Gegensatz zur gdb 
Kommandozeile.

Das Programm selbst funktioniert- ich habe es mit dem STM Flash Loader 
via serielles Interface flashen können.

In Eclipse habe ich nun versucht, nun auch mit dem Debugger zu arbeiten. 
Ich verwende die CodeSourcery Tool Chain, d.h. der Debugger ist 
arm-none-eabi-gdb.exe. Eclipse (Helios, CDT) habe ich entsprechend 
konfiguriert (siehe Attachment) Der GDB-Server von Segger ist in Eclipse 
via "Connection"-Tab einkonfiguriert.

Die Datei gdb_init hat folgenden Inhalt:
1
# Connect to the J-Link gdb server
2
set mem inaccessible-by-default off
3
target remote localhost:2331
4
monitor speed Auto
5
monitor endian little
6
# STM32F103RBT6
7
monitor flash device = STM32F103RB
8
monitor flash breakpoints = 1
9
monitor flash download = 1
10
file elf/main.elf
11
# Initializing PC and stack pointer
12
monitor reg r13 = (0x00000000)
13
monitor reg pc = (0x00000004)
14
load
15
break main
16
continue

Wenn ich den gdb direkt aus dem DOS Fenster starte und interaktiv die 
Kommandos eingebe , wird das Programm auf den STM32 geladen, der 
Breakpoint gesetzt und die Ausführung endet auch tatsächlich in main().

Wenn ich dagegen in Eclipse das Debuggen starte, zeigt der GDB-Server 
die gleiche Reaktion wie bei der direkten gdb-Eingabe (soweit gut), 
liefert dann aber noch eine Art Zugabe nachdem der Breakpoint erreicht 
ist und ärgert sich über ein Packet 'qSupported' (?).
1
 Starting target CPU...
2
...Breakpoint reached @ address 0x08000214
3
Reading all registers
4
Removing breakpoint @ address 0x08000214, Size = 2
5
Read 4 bytes @ address 0x08000214 (Data = 0x001CF04F)
6
Reading all registers
7
Read 4 bytes @ address 0x08000214 (Data = 0x001CF04F)
8
Debugger terminated connection !
9
10
Connected to 127.0.0.1
11
WARNING: Unknown packet received: "qSupported:multiprocess+"
12
Reading all registers
13
Read 4 bytes @ address 0x00000000 (Data = 0x20004FFF)
14
Read 4 bytes @ address 0x00000000 (Data = 0x20004FFF)
hinterher. In Eclipse kommt die Meldung
1
 Ignoring packet error, continuing...
2
warning: RMT ERROR : failed to get remote thread list.
3
warning: RMT ERROR : failed to get remote thread list.
4
warning: RMT ERROR : failed to get remote thread list.
Und zu allem Überfluß öffnet Eclipse die Datei '0x0' und vermeldet, daß 
hierfür "No source available for 0x0" (siehe Attachment #2).

Ich hatte vorher auch schon mal direkt in Eclipse Breakpoints definiert, 
die aber allesamt ignoriert wurden, d.h. ohne die Zeile 'break main' 
läuft das Target los und ich konnte nur noch "zuschauen".

Kann mir jemand dieses Verhalten erklären - was muß ich ändern, damit 
ich in Eclipse debuggen kann?


Grüße
schnack

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Angehängte Dateien:

Lesenswert?

Bei mir, Eclipse + Segger JLink sieht das so aus.

Initialize Commands:
1
target remote localhost:2331
2
monitor flash device = STM32F103RC
3
monitor flash download = 1
4
monitor flash breakpoints = 1
5
monitor speed 1000
6
load

Run Commands:
1
tbreak main
2
monitor reset 0
3
continue

(Das Fenster kann man größer ziehen)

Wichtig:
"GDB Hardware Debugging" links auswählen.

Installation ist im Artikel STM32 grob geschrieben.

von U. E. (Gast)


Lesenswert?

Hi Markus,
danke! Dann werde ich erstmal das GDB Hardware Debugging ermöglichen. 
Wie ich in http://download.eclipse.org/tools/cdt/releases/helios/ 
gelesen habe, muß ich dafür eine andere Installation wählen. Nun ja, 
Hauptsache es geht dann :-)

von U. E. (Gast)


Angehängte Dateien:

Lesenswert?

Hi,
hm. Das GDB Hardware Debugging ist nun installiert und ich habe die 
gleichen Einstellungen gewählt.
Als GDB command habe ich arm-none-eabi-gdb.exe gewählt und die 
Port-Angaben (2331) für den GDB-Server eingetragen.
Im Tab 'Main' habe ich unter 'C/C++ Application' die main.elf gewählt.

Ergebnis: Der Launch läuft durch bis 100%, danach ist Eclipse nicht mehr 
ansprechbar (Attachment).
Verwendet wird der GDB (DSF) Hardware Debugging Launcher. Die 
Alternative 'Standard GDB Hardware Debugger' bekomme ich noch weniger 
zum Laufen.

Grüße
schnack

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Der GDB Server ist aber an?
Und bietet auch wie der Segger-GDB Server einen Port 2331?

Es benötigt einen GDB Server, der die Umsetzung der über TCP/IP 
kommenden Befehle an den ST-Link weiter leitet. Das ist in der Regel ein 
Programm das muss laufen.

Das "GDB Hardware Debugging" kann nur die Verbindung zwischen Eclipse 
und "arm-none-eabi-gdb.exe" herstellen, nicht zur Debug-Hardware.
"arm-none-eabi-gdb.exe" kann nur über TCP/IP mit einem GDB-Server 
kommunizieren. (z.B. OpenOCD oder JLink GDBServer.) Wie das jetzt genau 
beim ST-Link geht weiß ich nicht, ich hab keinen. Nur das Prinzip ist 
gleich.

von U. E. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Markus,
Moment: ich verwende ja einen Segger J-Link. Und ja, der GDB-Server ist 
an, er wird auch beim Start des Debuggings angesprochen.
Ich habe mal Screen-Shots der weiteren Konfigurationstabs und die 
Ausgabe des Segger GDB-Servers beigefügt Vielleicht liegt hier ja noch 
ein Unterschied.
Grüße
schnack

von 900ss (900ss)


Lesenswert?

In dem Manual zum JLink steht recht gut beschrieben, wie man mit Eclipse 
debuggen kann (soll). In meinem Manual war das jedenfalls der Fall (ist 
schon ein Jahr her). Es sind sogar Beispiele dabei.

von U. E. (Gast)


Lesenswert?

Hi,
im GDB-Server Manual (und das ist das Einzige, in dem ich überhaupt 
einen Hinweis auf Eclipse gelesen habe) gibt es den Abschnitt 3.7.2 
"Eclipse". Leider ist hier auf einer 3/4-Seite nur allgemeines 
beschrieben. Den meisten Platz nimmt ein Screen Shot ein, der das 
funktionierende Debugging zeigt - aber leider nicht, wie man da 
hinkommt...
Vielleicht übersehe ich da auch etwas, habe aber nichts weiteres 
gefunden.

Für den gdb selbst findet sich eine gute Darstellung in "Setting up 
GDB", speziell auch für Cortex-M3.
Aber wollte ja gerne in Eclipse arbeiten. Und ich habe den Eindruck, daß 
es irgendeine Kleinigkeit ist, die noch fehlt damit es klappt.

Grüße
schnack

von U. E. (Gast)


Angehängte Dateien:

Lesenswert?

Hi,
jetzt klappt es. Ich  habe die Startup-Kommandos nach einer Art "best of 
mikrocontroller.net threads" ergänzt zu
1
set mem inaccessible-by-default off
2
target remote localhost:2331
3
monitor flash device = STM32F103RB
4
monitor flash download = 1
5
monitor flash breakpoints = 1
6
monitor speed 1000
7
file elf/main.elf

bzw. die 'Run Commands' der Cortex-M3-Segger-Empfehlung für den gdb 
geändert (gdb Server Handbuch, Kapitel 3.4, siehe attachment).
Den Breakpoint habe ich nun direkt in Eclipse gesetzt und er hält 
tatsächlich an!
Danke für die Tipps!
Grüße
schnack

von Lutz (Gast)


Lesenswert?

Wenn Du im Fenster auch "Load image" und "Load symbols" anklickst, 
üßtest Di Dir eigentlich auch die "file ..."-Zeile sparen können.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Angehängte Dateien:

Lesenswert?

Bei mir sehen die Debug Einstellung so aus

Im Bild1 die "Build Configuration" ist anders als bei dir.

Ansonsten mal SWD versuchen, dazu muss der GDB Server mit dem Parameter:
-if SWD
gestartet werden.

von U. E. (Gast)


Angehängte Dateien:

Lesenswert?

Hm,
so ganz klappt es wohl doch noch nicht. Der Download einer neuen SW via 
JTAG funktioniert nämlich nicht. Ich habe mal 'Load image' und 'Load 
symbols' ausgewählt.
Alternativ habe ich die "file elf/main.elf" Anweisung um ein "load" 
ergänzt. In beiden Fällen meldete der GDB-Server ein 
Verifikationsproblem mit dem Schreiben (attachment). Ich hoffe nicht, 
daß dies an meinem Breadboard-Aufbau liegt. Mein Stamp-Modul hat keinen 
JTAG-Anschluß, den habe ich ergänzt.
Grüße
schnack

von U. E. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Markus,
danke für Deine Konfiguration. Meine CDT Version (7.0.1) ist vermutlich 
jünger als Deine. Ich kann zwei Debugger Launcher auswählen. Im Fall 
'Standard GDB Hardware Debugging Launcher' habe ich das Menü so wie Du. 
Im anderen Fall (DSF-Variante), entfallen Optionen.
Das Ergebnis (Download klappt nicht) ist allerdings bei beiden Fällen 
gleich :-(
Grüße
schnack

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Ich nutze Eclipse Galileo

Mit meinem JLink gibt es beim Donwload ab und zu Probleme, allerdings 
ist es eine ältere Variante, Version 6.
Wenn der JLink noch älter ist, dann geht es nicht.
Der GDB Server meckert bei mir immer dass die Hardware (Varion 6) irgend 
ein feature nicht richtig unterstützt.

Bei mir kam dann allerdings eine Message-Box. (Ich hab das ganze gerade 
nicht aufgebaut)

Mit den Befehlen, wie ich gepostet habe ging es bei mir auch schon. Der 
JLink GDB Server hat auch nicht so viel Auswahl an Befehlen.

Ich arbeite hauptsächlich mit OpenOCD und Olimex ARM-USB-OCD.

von Jax (Gast)


Lesenswert?

Nur zur Ergänzung:

Es gibt von www.zylin.com ebenfalls ein Eclipse-CDT-Plugin,
das das Debuggen von Embedded-Systemen unterstützt.

Geht ganz gut mit OpenOCD + Turtelizer.

Jax.

von U. E. (Gast)


Lesenswert?

Hi,
ich nehme mal, die Empfehlung ging jetzt nicht so sehr an mich. Ich 
wollte ja den brandneuen J-Link nicht schon wieder ersetzen.
Das Problem mit der Verifikation ließ sich nun weiter eingrenzen. Es 
tritt auch auf, wenn ich direkt im gdb die Anweisungen durchführe.

Ich habe dann das Programm mit dem STM FlashLoader über die serielle 
Schnittstelle geladen - funktionierte.

Tja, damit aber erst mal die Weisheit...

Grüße
schnack

von U. E. (Gast)


Angehängte Dateien:

Lesenswert?

So, jetzt aber:
Ich habe zwei Fehler korrigiert:
a) Der Controller selbst ist nicht der STM32F103R B T6, sondern 
STM32F103R E T6. Der Schaltplan von steitec.net war hier nicht 
richtig- ich hätte aber schon eher darauf kommen können. Denn E 
bezeichnet 512K Flash und soviel Speicher hat der Controller laut 
Angebot von steitec.net.
b) Ich habe in der CDT 7.0.1 zwei Möglichkeiten den gdb zu starten: den 
Standard GDB Hardware Debugging Launcher (funktioniert, zeigt auch in 
der Console, was er gerade macht) und den GDB (DSF) Hardware Debugging 
Launcher (geht nicht bzw. hängt gerne mal und verrät nicht, woran er 
gerade scheitert, da keine Console Ausgabe)

Meine Konfiguration, mit der es nun geht, ist bei den 
Initialisierungskommandos:
1
set mem inaccessible-by-default off
2
target remote localhost:2331
3
monitor speed Auto
4
monitor endian little
5
# STM32F103RET6
6
monitor flash device = STM32F103RE
7
monitor flash breakpoints = 1
8
monitor flash download = 1

und bei den Run Commands:
1
monitor reg r13 = (0x00000000)
2
monitor reg pc = (0x00000004)
3
monitor reset
4
continue

Ansonsten: wie im Attachment :-)

Nochmals: vielen Dank für den Support!

von U. E. (Gast)


Lesenswert?

Zur Klarstellung: Ich habe das Modul ARM STM32F103 / 512 Stamp 
verwendet:
http://www.steitec.net/ARM-Stamp-Module/ARM-STM32F103---512-Stamp.html.
Grüße
schnack

von Sebastian H. (sh______)


Lesenswert?

Hallo,
ich habe auch probleme beim Debuggen unter Eclipse.

Die Parameter habe ich so wie hier auch eingestellt. Der Debugger 
startet so auch und hält Ordnungsgemäß bei main() an. Zu diesem 
Zeitpunkt kann ich auch im Programm Breakpoints setzten. Lasse ich das 
Programm nun aber weiterlaufen (Resume/F8) kann ich das Programm weder 
stoppen (der SuspendButton ist inaktiv) und auch Breakpoints kann ich 
keine mehr setzten -> Unresolved breakpoint

Außerdem habe ich das problem wenn ich die Debugsession beenden will 
(Terminate) kommt ebenfalls eine Fehlermeldung und ich kann eine neue 
Session erst wieder erfolgreich starten wenn ich den JLINK GDB Server 
neu starte.

Also Controller hab ich einen LPC1768, aber das sollte ja egal sein. Ist 
ja auch nen CortexM3. Die Device-Einstellung habe ich natürlich 
entsprechend angepasst.
Als JTAG benutze ich ebenfalls den J-Link Edu.


Ich hoffe ihr habt nen paar Tipps wie man mit Eclipse vernünftig 
debuggen kann.

Gruß
Sebastian

von U. E. (Gast)


Lesenswert?

Hallo Sebastian,
das ist natürlich nicht so ohne weiteres zu sagen. Meine Erfahrung ist: 
Wenn man in so einem Fall nicht mehr "rankommt", hat sich der Controller 
in irgendeinen System-Interrupt "eingegraben" (z.B. Hard Fault) und 
befindet sich dort in einer Endlosschleife. Ich habe mich dann 
step-weise an die Anweisung herangehangelt, bei der der Interrupt 
ausgelöst wurde.

Woher ich das mit dem Interupt weiß? Ich habe denselben Code mal mit 
Keils uvision debugged - dort behält man den Kontakt zum Controller. Und 
damit konnte ich auch sehen, wo der Controller hängen blieb.
Eclipse ist leider nicht erste Wahl beim HW-Debuggen..

Grüße
schnack

von Sebastian H. (sh______)


Lesenswert?

Das er in einem Interrupt hängen bleibt kann ich eigentlich 
ausschließen, da die LEDs weiter laufen. Also funktioniert alles noch 
Ordnungsgemäß.

Wie gesagt wenn ich vor dem Starten auf der LEDToggle funktion nen 
Breakpoint lege stoppt der Debugger ohne Probleme immer genau dort. 
Lösche ich dann den Breakpoint laufen die LEDs auch genau so weiter wie 
gewünscht. Will ich jetzt den Breakpoint an genau der gleichen Stelle 
setzten geht es nicht mehr -> Unresolved breakpoint

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.