Hallo, ich arbeite mit Eclipse 3.3.0 unter Windows und versuche z. Z. das Flashen so gut wie es geht zu automatisieren. Im Moment habe ich den Flashvorgang über das makefile realisiert (OCD-Server starten, flashen, Server beenden). Aber ich halte das nicht für eine elegante Lösung. Wenn das Flashen innerhalb der "all" Regel durchgeführt wird (also bei jedem Build), dann wird viel zu viel geflasht, selbst dann, wenn es gar nicht notwendig ist und der Flash-Speicher wird dadurch zu sehr beansprucht. Ich möchte aber auch keine eigene Regel dafür erlassen. Für mein Arbeitsumfeld wäre es die eleganteste Lösung den Flashvorgang vor dem Start des Debuggers (arm-elf-gdb) voll automatisiert durchzuführen. Wenn hierfür jemand einen Ansatz hat, dann wäre ich sehr dankbar. Man könnte das ganze dann später auch noch weiter perfektionieren, indem vor jedem Flashvorgang anhand des Datums des Binär-Files geprüft wird ob dieses neuer ist als das zuletzt geflashte Binär-File. Somit würde man nur noch flashen, wenn dies auch wirklich erforderlich ist. Hier noch mal der gesamte Ablauf: 1. OpenOCD-Server starten 2. prüfen ob das Binär-File neuer ist als das zuletzt geflashte 3. wenn ja, dann flashen (entsprechendes Script dafür ist vorhanden) 4. Debugger starten 5. nach verlassen des Debugmodus den OpenOCD-Server beenden Ich bin mir nicht sicher, ob "Debugger starten" an 4. Position so richtig ist, es wäre dabei zu klären, ob man vielleicht über das .gdbinit File als erste Aktivität den OCD-Server starten kann? Oder allgemein gefragt: Kann man über das .gdbinit File einen Prozess starten? Ich bin für jede Hilfe dankbar und hoffe, dass wir gemeinsam eine Lösung erarbeiten können!
Habe dafür zwei Debug-Konfigurationen angelegt. Eine davon mit und eine ohne vorheriges Flashen. Ist zwar nicht vollautomatisch, aber die Auswahl der Debug-Konfiguration ist nur ein Mausklick (evtl. zwei wenn eine andere Konfiguration vorher beendet werden muss). OpenOCD läuft ständig in Hintergrund. OpenOCDs gdb-Server unterstützt den gdb load Befehl. Meine Eclipse "start debug mit flashen"-Konfiguration entspricht der Konfiguration "start debug ohne flashen" bis auf zwei zusätzliche Anweisungen in "Initialization Commanand" des GDB hardware debugging plugins: monitor flash probe 0 load wobei flash probe mglw. redundant ist und "load" gibt es auch als Checkbox im GDB hardware-debugging-plugin. In der OpenOCD-Konfiguration ist gdb_flash_program enabled eingetragen, dies ist aber wenn richtig erinnert schon per default an. Für "manuelles Flashen" (was man eigentlich nicht mehr braucht) habe ich per "External Tools"-Konfiguration gelöst, die eine Batch-Datei/Shell Script aufruft, die wiederum per netcat mit dem Telnet-Interface des laufenden OpenOCD "spricht". Man braucht dann OpenOCD nicht zu beenden, um zwischendurch den Flash-Inhalt zu aktualisieren ohne eine Debug-Session zu starten. OpenOCD Konfiguration ist natürlich vom Target abhängig, hier getestet mit: - AT91SAM7SE512, Eclipse 5.x inkl. GDB hardware debug-plugin, OpenOCD SVN922, JTAGkey - LPC2378, Eclipse dito, OpenOCD SVN97?
Martin Thomas wrote: > Habe dafür zwei Debug-Konfigurationen angelegt. Eine davon mit und eine > ohne vorheriges Flashen. Ist zwar nicht vollautomatisch, aber die > Auswahl der Debug-Konfiguration ist nur ein Mausklick (evtl. zwei wenn > eine andere Konfiguration vorher beendet werden muss). OpenOCD läuft > ständig in Hintergrund. Hab das ausprobiert, würde so funktionieren, wenn da nicht wieder ein kleines Problem wäre... Ich habe schon andere Teile des Entwicklungsprozesses automatisiert und dabei wird bei jeder Aktivität mit dem Controller davon ausgegangen, das der OCD-Server erst gestartet werden muss, und danach wird er gleich wieder beendet, so dass jede Nachfolgeaktivität immer den gleichen Ausgangszustand vorfindet. Es wäre mir auch lieber der OCD-Server würde immer laufen, aber dazu wäre es notwendig meinen Telnet-Client (Putty) Makros übergeben zu können. Ich habe das ausprobiert, es gibt da eine Kommandozeilenoption –m mit der man eine Befehlsdatei übergeben kann, aber die Befehle werden serverseitig einfach nicht ausgeführt. Das hat mich dazu gebracht den Server ständig neu zu starten, weil ich in der OCD Konfiguration ein Script zur Abarbeitung nach Neustart des Servers übergeben kann. Ich stecke hier in einer Sackgasse und komme einfach nicht mehr vorwärts.
@MT: Können Sie mir bitte schreiben woher ich das "GDB Hardware Debugging" bekommen? Ich habe Eclipse 3.4, das kann doch sicher unter Menü "Help" >> "Software-Updates..." einfach installiert werden. Welchen Link tippe ich da ein? Wo kann ich eigentlich eine neuere OpenOCD.exe laden? Yagarto bietet die 717, irgend wo anders habe ich die 994 her, weiß aber nicht mehr wo. Im SVN ist die >=1100 schon vorhanden. Leider bin ich nicht im Stande die Umgebung für die SVN Version ein zu richten (Es scheitert schon an SVN selbst, und ...) Es wäre toll wenn es im SVN ein Ordner "LastEXE" gäbe, von der man die sich einfach ziehen könnte... PS: Auf der Seite "Accessing ARM-Controllers with OpenOCD" fehlt unter "Initialisation Commands:" folgender Befehle: target remote localhost:3333 Ohne den klappt die GDB Verbindung zum OpenOCD nie. Ansonsten hat die Anleitung für den "NXP LPC23xx/24xx" super geklappt, nur noch die Anpassung an meinen JTAG-Dongle war nötig (aber das muss ja sowiso jeder ...) Diesen einen Link von ^^ bitte auch auf dieser Seite dokumentieren.
Markus wrote: > @MT: > Können Sie mir bitte schreiben woher ich das "GDB Hardware Debugging" > bekommen? > Ich habe Eclipse 3.4, das kann doch sicher unter Menü "Help" >> > "Software-Updates..." einfach installiert werden. Welchen Link tippe ich > da ein? Link war hier nach Installation des Eclipse+CD-Pakets schon eingestellt: http://download.eclipse.org/tools/cdt/releases/ganymede Dann: Software Upd. and Add-on->Available Software->CDT Opt. Feat.-> Eclipse GDB Hardw. Debug. > Wo kann ich eigentlich eine neuere OpenOCD.exe laden? Meines Wissens gibt es keine "nightly builds". Neuere manchmal von mir (s.u.). > Yagarto bietet die 717, irgend wo anders habe ich die 994 her, weiß aber > nicht mehr wo. Mglw. von mir, ist zumindest eine der Versionen, für die ich ein Binärpaket bereitstelle. > Im SVN ist die >=1100 schon vorhanden. Leider bin ich > nicht im Stande die Umgebung für die SVN Version ein zu richten (Es > scheitert schon an SVN selbst, und ...) > Es wäre toll wenn es im SVN ein Ordner "LastEXE" gäbe, von der man die > sich einfach ziehen könnte... Ich bau mir OpenOCD f. Win32 inzwischen immer selbst. SVN-checkout mittels einem Linux-Rechner nebenan (gibt aber auch Win32 SVN clients), weiters auf einem PC unter WinxXP, MinGW/msys zum Bau der "exe", MiKTeX für Doku. Methode so aber kaum für ein automatisiertes "nightly-build" geeignet. Manchmal stelle ich das Ergebnis als OpenOCD_package_*_mthomas.zip auch auf www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects(/winarmtests) (derzeit SVN1131 vorhanden). > PS: Auf der Seite "Accessing ARM-Controllers with OpenOCD" fehlt unter > "Initialisation Commands:" folgender Befehle: > > target remote localhost:3333 Ergänzt. Danke. > Ohne den klappt die GDB Verbindung zum OpenOCD nie. Ansonsten hat die > Anleitung für den "NXP LPC23xx/24xx" super geklappt, nur noch die > Anpassung an meinen JTAG-Dongle war nötig (aber das muss ja sowiso jeder > ...) > Diesen einen Link von ^^ bitte auch auf dieser Seite dokumentieren. Getan. OpenOCD ist aber derart im Fluß, dass man kaum hinterherkommt. Meine Anleitungen auf der o.g. Seite sind schon veraltet oder werden schnell veralten (steht auch im "Vorwort"). Bin dazu übergegangen, in jedem Projekt ein extra Unterverzeichnis mit dem verwendeten OpenOCD anzulegen als "feature freeze".
@MT: Vielen Dank für die Ausführliche Antwort! (Und auch Ihr sehr aktives Zutun für die ARM Freunde... Diese Seiten haben mir sehr geholfen) Genau so einen Link hab ich gesucht, wo alle 2-4 Wochen ein neues OpenOCD zu finden ist, vielen Dank! > OpenOCD ist aber derart im Fluß nicht nur OpenOCD, auch Eclipse, Compiller, debugger usw. Ich habe mir ein "arm-elf", "arm-none-eabi", OpenOCD, Eclipse, Demos usw. Paket zusammengabaut, das ich ohne Probleme (nur PATH-Variable) kopieren kann. (ca. 700MB / 19000Files). Bis das lief (neuanfänger) brauchte ich sicher 2 Monate beschäftigt... Jetzt kann ich ARM7 und Cortex problemlos kompillieren, nur mit dem LPC2368/Olimex JTAG hatte ich noch Probleme. Aktuelle Probleme habe ich noch mit der SWD-Schnittstelle des Cortex. Irgendwie funktioniert der Cortex nur mit der JTAG. Haben Sie schon Erfahrung mit dem SWD Interface? Ich habe auch einen SEGGER JLink (V6) aber der funktioniert viel schlechter als der Olimex ARM-USB-OCD, daher liegt der nur rum. (Kaum Unterstützung von Segger) Wenn ich SWD noch zum laufen bekommen würde ist die Entwicklungsumgebung perfekt.
@ Martin Thomas: Danke für DIESEN Link, nach prebuild Binaries habe ich schon öfters erfolglos gesucht!
Es gibt das monitor Kommando vom GDB. "monitor flash ..." führt also "flash ..." in openocd aus. Das kann man sich dann in die .gdbinit (oder wie sie genau heisen mag) hineinschreiben. Viele Grüße, Martin Laabs
Wobei das flashen so nur mit von OpenOCD unterstützten Chips funktioniert. Ich flashe meine ADUC7000, in dem ich zu erst per REgister flashen erlaube und dann die Daten direkt reinlade.
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.