Hallo Formmember, Ich habe mir die Eclipse-Entwicklungsumgebung so angepasst (wie in vielen Tutorials im Internet beschrieben) das ich damit auf mein STM32F107VCT Board via J-Link Debuggen kann. Dafür verwende ich den J-Link GDB Server und den Debugger von Code "Sourcery -> Sourcery G++" (arm-none-eabi). Meine Eclipseversion ist Juno. Nun zu meiner Frage, das Kompilieren des Demoprojektes, sowie das Debuggen funktionieren einwandfrei. Nur ich hätte gerne den Inhalt / die Werte von Variablen während des Debuggens in meiner Variablen View angezeigt. Nur immer wenn ich das Debuggen starte erscheint "Error: Target not available". Im Grunde genommen hätte ich gerne einen Live View für Variablen. Ich weis das es möglich ist, da ich es in der Entwicklungsumgebung "IAR - Embedded Workbench" mit gleicher Hardware auch sehen konnte. Habt ihr irgendwelche Tipps? Danke schon mal im voraus!
:
Bearbeitet durch User
PUSH.. kann mir denn keiner helfen? Sorry für den Doppelpost..
Was genau verstehst du genau unter "live"? Bei mir geht das mit eclipse und dem gdb aus dem gcc-arm-embedded und dem J-Link GDB-Server.
Ich würde gern während des Debuggens ohne den Debugger anzuhalten den Wert von Variablen sehen. Das heißt die sollen zyklisch jede Sekunde aktualisiert werden.
Das geht mit GDB gar nicht, macht auch kaum Sinn weil man so "Per Zufall" einige der Werte sieht und das nicht sonderlich deterministisch ist. Du musst halt eine "richtige" Übertragungstechnik nehmen um "live" Daten zu übermitteln.
Was für eine "richtige" Übertragungstechnik muss ich da Benutzen? Ich meine es sollte ja mit meinem J-Link und dem STM3210c Board gehen, da es in IAR auch funktioniert. Gibt es da irgendeinen Link auf den Sie verweisen können? Danke schonmal für die Aufklärung.
mit Keil und J-Link funktioniert es, kann also nicht am J-Link liegen
Richtig und wurde ja auch nie behauptet.. "Dr.Sommer" meint ja nicht es liege an J-Link sondern an dem GDB-Server. Deshalb meine Frage was stattdessen nutzen? Wie heißt hier die "richtige" Alternative.
Es liegt am GDB selber. Verwende einen anderen Debugger wie den von Keil. Oder schreibe dir eine richtige Live-Übertragung.
Phil B. schrieb: > .... > Debuggen funktionieren einwandfrei. ... > ...Nur immer wenn ich das Debuggen starte erscheint "Error: > Target not available". Hmmm.... was denn nun? Kannst du debuggen, also das Programm im Debugger starten oder nicht? Wenn das geht, dann kannst du auch die Variablen ansehen. Natürlich nur, wenn du das Programm mittels Breakpoint oder "Break" angehalten hast. Während es läuft, geht das nicht.
Auch wenns schon ne Zeit lang her ist - ich kann WinIDEA Open von iSystem empfehlen. Ist kostenlos verfügbar. Damit funktioniert der RealTimeView von Variablen SFRs Memory. Auch habe ich sonst Probleme beim GDB Debuggen über Eclipse, dass mir beim DisassemblerView im MixedMode die Source Zeilen ständig hin und her springen. HOWTO - siehe hier: http://www.segger.com/IDE_Integration_winIDEA.html
mit meinem Tantino von Hitex funktioniert die Live Speicheranzeige auch prima, wenngleich ich das Teil sonst hasse weil es viele andere Mankos hat. Mit Coocox und dem ST-Link habe ich das auch nicht zum laufen gekriegt und die Funktion ist ja eine HW Eigenschaft des STM32 bzw. dessen jtag/swd Schnittstelle und nicht unbedingt des Debuggers. Ich habe auch Zweifel daß es am gdb liegt, weil der Peedi (von ronetix.at) stellt auch auf einen gdb Server auf HW Basis dar und von dem habe ich gehört daß es funktionieren soll (Anzeige über Eclyplse).
J. V. schrieb: > habe auch Zweifel daß es am gdb liegt Dann probiers halt aus. eclipse macht ja nichts anderes als den GDB zu starten und ihm Befehle zu senden, kann also nicht mehr tun als der GDB kann. Starte den GDB manuell von der Konsole, starte ein Programm damit auf deinem STM32, und lass es laufen (befehl "continue"). Zeigt GDB irgendwelche Variablen an? Kannst du irgendwelche Befehle eingeben? Nein, denn GDB macht solange gar nichts bis das Programm anhält (durch crash, breakpoint, watchpoint...) oder du es per Ctrl+C anhälst. Die einzige Möglichkeit die es gäbe wäre den GDB regelmäßig anzuhalten und den Speicher auszulesen. Nur wenn man das 10x pro Sekunden macht bringt das nicht viel wenn sich der Wert 1000x ändert. Oder sich der Wert in genau dem Moment ändert wo man ihn ausliest und man so was ganz verkorkstes erhält.
normalerweise ändern sich die Werte etwa so schnell wie der zu steuernde Prozess und da kann ich zumindest bei mir in der Regel gut zuschauen. Deshalb habe ich mich an den Komfort des Debuggers gewöhnt und bin bislang ohne eigene Variablenausgabe zum Debuggen über die Runden gekommen. Früher hatte ich das beim HC05 und Z80 auch selbst geschrieben. Zumindest bei Zielsystemen die ein eigenes Display oder eine freie Schnittstelle oder beides hatten. Wenn gdb eine solche HW Unterstützung der Debug Schnittstelle nicht anzeigen kann halte ich das für eine konzeptionelle Schwäche und da nutzt es nichts, wenn man das mit einer Bemerkung abtut, dass die Funktion ohnehin sinnlos ist. Bei umfangreichen Anzeigen wie etwa Tabellen habe ich übrigens festgestellt, daß zumindest beim meinem Hitex Tantino die Rechenzeit am Zielsystem (im einstelligen Prozentbereich) etwas einbricht. Es scheint also zumindest irgendwelche Wait Zyklen zu geben.
J. V. schrieb: > Wenn gdb eine solche HW > Unterstützung der Debug Schnittstelle nicht anzeigen kann halte ich das > für eine konzeptionelle Schwäche GDB ist ja auch eigentlich zum Debuggen von Konsolen-UNIX-Programmen konzeptioniert, und nicht zum Debuggen von Embedded-Anwendungen in denen man seine Werte nicht einfach per printf() ausgeben kann. Die große Stärke von GDB ist das Protokoll, dank dem jede GDB-fähige Oberfläche (wie eclipse) mit jedem GDB-fähigen Hardware-Debugger funktioniert (wie J-Link). Bei nicht-GDB-Systemen müsste eclipse jeden Debugger einzeln direkt unterstützen...
Habe heute mit dem Peedy probiert. (Peedy stellt als eigenständige Hardware einen gdb Server im Netzwerk dar) Die live Anzeige der Variablen geht (Dank gdb) wirklich nicht. Wie auch bei Coocox auf gdb Basis mit STlink blos 1500 Euro teurer. Das gdb Protokoll scheint mir eine eierlegende Wollmilchsau die aber beim Fliegen an ihre Grenzen gerät. Also noch ein Grund mal nachzuschauen wie gut das winIDEAOpen von iSystem fliegen kann. Milch und Eier kaufe ich derweil bei Aldi und Lidl ein. Der Weg bis zum printf() kann bei uC im Übrigen recht steinig sein. Je nach Lib gibt das gleich mehrere kilobyte Code und selbst wenn man sich sowas abgespeckt selbst schreibt hat das uC System nicht unbedingt auch ein Display
Dr. Sommer schrieb: >Das geht mit GDB gar nicht, Offensichtlich soll es bei emBlocks gehen und der basiert ja auch auf gdb http://www.emblocks.org/web/ Gleich auf der Startseite liest man: EmBlocks can use any debug probe and is not limited to one type or brand. The integrated STlink GDB server also supports Live Data and Semihosting.
Ich arbeite nun schon länger mit emBlocks. Zum einen weil das Compilieren echt fix geht und zum anderen wegen des Debuggers. Entweder legt man sich watches an oder man geht mit der Maus über die Variable im source code deren Inhalt man sehen will. Gerade die watches ersparen einen Arbeit weil man sich nicht umständlich die Daten über sprintf ausgeben muss. Seit der letzten Version gibt es auch RTOS Unterstützung.
:
Bearbeitet durch User
J. V. schrieb: > Offensichtlich soll es bei emBlocks gehen > und der basiert ja auch auf gdb Dann haben sie das vermutlich so gemacht dass alle 1sec das Programm angehalten und die Werte abgefragt werden, oder so. Jörg B. schrieb: > Zum einen weil das > Compilieren echt fix geht Das hat mit emBlocks nichts zu tun, das ist (wer hätte es gedacht) Sache des Compilers, und der ist bei den ganzen freien Sachen immer GCC, und somit ist zB eclipse genauso schnell. > und zum anderen wegen des Debuggers. Entweder > legt man sich watches an oder man geht mit der Maus über die Variable im > source code deren Inhalt man sehen will. Das kann so ziemlich jede IDE mit Debugger-Support, inkl. eclipse. Also kein Alleinstellungsmerkmal...
Dr. Sommer schrieb: > Das kann so ziemlich jede IDE mit Debugger-Support, inkl. eclipse. Also > kein Alleinstellungsmerkmal... Dann mach doch mal einen Bildschirmdruck und stell den hier online. Dr. Sommer schrieb: > J. V. schrieb: >> Offensichtlich soll es bei emBlocks gehen >> und der basiert ja auch auf gdb > Dann haben sie das vermutlich so gemacht dass alle 1sec das Programm > angehalten und die Werte abgefragt werden, oder so. Wie sie es machen spielt ja nun keine Rolle. Ich weiß nur, dass Segger es mit seinem J-Link GDB Server auch gerne machen würde. Bis heute aber nicht realisiert ist. emIde auch auf Code Blocks basiert will dieses Feature auch gerne anbieten. "Upcoming features Following features are planned for future versions of emIDE: Writing peripheral register values. Variable information on mouse-over. " Der Verantwortlicher/Autor: Johannes Lask von emIde ist Angestellter bei Segger, ein Schelm denke jetzt etwas schlechtes... :D
Angehängte Dateien:
-
eclipse.png
180 KB
Jörg B. schrieb: > Dann mach doch mal einen Bildschirmdruck und stell den hier online. Man glaubt mir nicht... Siehe Anhang. > Dr. Sommer schrieb: > Wie sie es machen spielt ja nun keine Rolle. Naja, schon. Es wird halt der GDB ein bisschen "vergewaltigt", weil er das eigentlich nicht kann. > Ich weiß nur, dass Segger es mit seinem J-Link GDB Server auch gerne > machen würde. Bis heute aber nicht realisiert ist. Wenn die IDE das einfach nur 1x pro Sekunde o.ä. abfragt, muss Segger da gar nichts am Server machen, sondern es muss nur das Feature in die IDE eingebaut werden. Segger könnte dazu zB ein Patch an eclipse-cdt senden... > Der Verantwortlicher/Autor: Johannes Lask von emIde ist Angestellter bei > Segger, ein Schelm denke jetzt etwas schlechtes... :D Macht lieber mal folgendes: * JFlash soll auch .elf Dateien einlesen können * Bringt die Syntax der Kommandos für JLinkExe in ein einheitliches Schema, das ist ja gruselig so * Eingabe von EOF (Ctrl+D) oder "quit" in JLinkExe soll es beenden * Kommandozeilenoption "--help" für JLinkExe und JLinkGDBServer * Gebt Warn/Fehler-Meldungen aus, wenn man versucht über GDB zu flashen ("load" Kommando), aber man zuvor vergessen hat das richtige Device einzustellen (per "mon flash device xxx") und das Flashen somit nicht funktioniert - man sucht sich einen Wolf bis man feststellt dass der Flash-Vorgang einfach gar nichts bewirkt weil man die Einstellung vergessen hat. * Der JLinkGDBServer soll unter Linux erkennen wenn man das J-Link vom USB trennt, dann die Verbindung zum GDB trennen, und ein Neu-Anschließen des J-Link erkennen und dann auch wieder GDB-Verbindungen annehmen. Es ist leicht nervig das immer neu starten zu müssen wenn man den J-Link getrennt hat. * Ein eclipse-Plugin schreiben oder einen Patch an das vorhandene ( http://gnuarmeclipse.livius.net/blog/ ) senden, um einen Button in die Debug-Toolbar einzubauen, welches "mon reset X" (X konfigurierbar) an den GDB sendet. Gibts eigentlich eine Doku für die J-Link DLL (bzw .so unter Linux)? Damit könnte man sich eine nettere GUI für Linux bauen oder ein eclipse-Plugin.
Dr. Sommer schrieb: > Dann haben sie das vermutlich so gemacht dass alle 1sec das Programm > angehalten und die Werte abgefragt werden, oder so. Nein, das geht nicht in embedded Systemen. https://sourceware.org/gdb/onlinedocs/gdb/Non_002dStop-Mode.html
Stephan schrieb: > Nein, das geht nicht in embedded Systemen. Wieso nicht? "Von Hand" direkt in GDB geht's, aber per IDE nicht? > https://sourceware.org/gdb/onlinedocs/gdb/Non_002dStop-Mode.html Ja non-stop geht wohl nicht auf bare-metal. Und?
Dr. Sommer schrieb: > Wenn die IDE das einfach nur 1x pro Sekunde o.ä. abfragt, muss Segger da > gar nichts am Server machen, sondern es muss nur das Feature in die IDE > eingebaut werden. Segger könnte dazu zB ein Patch an eclipse-cdt Der GDB-server muss Asynchroner Modus Unterstützen und das geht nicht mit dem Jlink.
Stephan schrieb: > Der GDB-server muss Asynchroner Modus Unterstützen und das geht nicht > mit dem Jlink. Doch, das geht. Habe ich selbst ausprobiert. Versuchs mal selber: * JLinkGDBServer starten * gdb starten * Programm laden und ausführen. Wiederhole dies 1x pro Sekunde: Ctrl+C drücken mit "print" die gewünschten Variablen ausgeben mit "c" das Programm weiter laufen lassen Ich schätze mal genau so machen es die IDE's die Live View unterstützen. Oder weißt du wie die das machen?
Dr. Sommer schrieb: > Stephan schrieb: >> Nein, das geht nicht in embedded Systemen. > Wieso nicht? "Von Hand" direkt in GDB geht's, aber per IDE nicht? >> https://sourceware.org/gdb/onlinedocs/gdb/Non_002d... > Ja non-stop geht wohl nicht auf bare-metal. Und? Du kannst ein Control System nicht einfach halten, zb DSP Algorithmus
Dr. Sommer schrieb: > Stephan schrieb: >> Der GDB-server muss Asynchroner Modus Unterstützen und das geht nicht >> mit dem Jlink. > Doch, das geht. Habe ich selbst ausprobiert. Versuchs mal selber: > * JLinkGDBServer starten > * gdb starten > * Programm laden und ausführen. > Wiederhole dies 1x pro Sekunde: > Ctrl+C drücken > mit "print" die gewünschten Variablen ausgeben > mit "c" das Programm weiter laufen lassen > > Ich schätze mal genau so machen es die IDE's die Live View unterstützen. > Oder weißt du wie die das machen? Das ist nicht Asynchrone aber das ist Synchrone. Aber versuch mall selbst.
Stephan schrieb: > Du kannst ein Control System nicht einfach halten, zb DSP Algorithmus Kann man schon. Und genau das meinte ich ganz am Anfang >.> Stephan schrieb: > Das ist nicht Asynchrone aber das ist Synchrone. Ach. Und wie geht das dann hier? -> J. V. schrieb: > The integrated STlink GDB server also supports Live Data and > Semihosting. Faken eines non-stop-mode trotz nicht vorhandenen Multithreadings?
Dr. Sommer schrieb: >> Du kannst ein Control System nicht einfach halten, zb DSP Algorithmus > Kann man schon. Viel Glück! Drei IDE's, Keil, IAR und Emblocks Unterstützen Live data richtig , und Emblocks ist frei.
Stephan schrieb: > Drei IDE's, Keil, IAR und Emblocks Unterstützen Live data richtig , und > Emblocks ist frei. Nein, Emblocks nutzt GDB, und der kann das nicht: Stephan schrieb: > Nein, das geht nicht in embedded Systemen.
Dr. Sommer schrieb: > Nein, Emblocks nutzt GDB, und der kann das nicht: Doch, das ist warum wir Emblocks brauchen (DSP). Aber versuch mall selbst.
Aber nicht mit Jlink nur mit STlink (STlink ist besser für STM32 so das ist kein Problem). Wir brauchen das Jlink nicht mehr für die STM32 Familien. STlink ist billiger und Emblocks unterstutz Live data.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.