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' (?).
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
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 :-)
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
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.
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
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.
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
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
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.
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
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
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.
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.
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
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!
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
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
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