Eclipse ist eine wirklich tolle und leistungsfähige Entwicklungsumgebung. Aber wie kann ich damit einen LPC23xx debuggen? Was brauche ich für Hardware und Software? Geht das mit dem Arm-Elf-GDB? Ich möchte gerne aus dem Flash heraus debuggen und kann daher nur HW-Bkpts verwenden. Vielen Dank für eure Hilfe. Grüße Markus
Benutze auch Eclipse mit GNUARM und bin damit prima zufrieden. Allerdings habe ich das Debuggen mit Eclipse auch nicht hinbekommen. Benutze jetzt eine externen Debugger. Ist dein Project Hobby oder für die Firma ?
Ich bin eine kleine Ein-Mann-Firma, und diese auch nur nebenberuflich. Das ist eher ein Hobby von mir.
Ok, wenns kein Hobby ist wäre zu überlegen, ob man nicht doch paar Euro für einen ordentlichen Debugger investiert. Das Geld holt man locker durch die Zeitersparnis wieder rein. Ist jedenfalls meine Erfahrung. Musst du selber wissen. Falls du es doch mit Eclipse schaffen solltest, poste mal was man machen muss dass es geht. Viel Spass dann weiter.
Bin in der glücklichen Lage mir bei Bedarf einen Lauterbach ICD ausleihen zu können. Compiler wie gesagt GNUARM unter Eclipse_EU.
Ein Lauterbach ist natürlich schon ein starkes Teil... Meine Umgebung habe ich von Yagarto geladen, das Kompillieren und Flashen klappt auch. Ich habe leider keinen Zugriff auf einen Debugger, nur auf einen Olimex USB JTAG Key (das mit einem OpenOCD theoretisch funktionieren sollte, aber eben nur theoretisch, praktisch geht nix).
Hallo, ich habe auch mit Yagarto auf dem lpc2378 angefangen, als JTAG Tool habe ich mir ein ARM_USB_TINY von Olimex angeschafft. Das Flashen und Debuggen funktionierte leidlich,aber es gab immer wieder "Hänger", die sich nur durch Ziehen des USB-Kabels und Neuinitialisierung beheben liessen. Debuggen zeitkritischer Routinen (z.B. SD-Karte lesen) ging gar nicht, irgendwie schien der Debugger den Prozessor immer wieder für einige Zeit stillzulegen, so dass Daten-Fifos überliefen. Ich bin jetzt auf Keil umgestiegen, mit einem ULINK-Clone von Minford als JTAG-Adapter. Jetzt habe ich keine Probleme mehr mit dem Debuggen, alles lief auf Anhieb problemlos. Fazit: Zum Entwickeln ist Eclipse nicht schlecht, aber der Olimex-Dongle taugt nichts. Leider wird der Keil Ulink nicht von Eclipse unterstützt. Gruss Mike
Warum das USB Kabel immer gezogen werden musste habe ich heraus gefunden: Der OpenOCD verbiegt dermasen den JTAG Port des Prozessors, dass nicht einmal ein Reset des Reset-Pins hilft. Einzige Abhilfe: Pin TRST (Reset des JTAG Ports) auf Low ziehen. Dann klappt es auch ohne USB Stecker ziehen. Aber das Debuggen geht immer noch nicht, nur hat man weniger Arbeit... Hat jemand Erfahrung mit dem OCDRemote?
Hallo, wollte nur mal eben schreiben das ich es auch nach langem und mühseligem "rumeseln" geschafft den LPC2378 auf dem Olimexboard unter Eclipse mit dem Olimex USB-JTAG Adapter zu flashen und das Debuggen zu starten. Leider habe auch ich feststellen müssen, dass sich der Debugger schon in einer simplen Endlosschleife reproduzierbar "aufhängt". Vielleicht gibt es dort ja auf Dauer noch Abhilfe von den Entwicklern, ich würde mich freuen. Falls jemand den Editor "Codewright" von Borland kennt, würde mich interessieren in wie weit Eclipse dessen Funktionalitäten abbilden kann. Bis jetzt bin da ein wenig enttäuscht, konnte mich aber auch noch nicht aus Zeitgründen sehr lange damit beschäftigen. PS: hat jemand schon ein Olimexboard gesichtet wo "REV B" verbaut wurde. Aud meinem ist nur die total "verbugte" erste Revision verbaut. Besten Dank Microman
Die "Codewright" Entwicklung wurde eingestellt. Auch die Tasking-IDE, die die Codewright-Engine beinhaltete wurde leider auf Eclipse umgestellt. (news von der EW 2008) Code::Blocks bildet derzeit eine gute Alternative zu Eclipse.
Für die Kombination Eclipse + GDB gibt es das Zylin Plugin, das bei Yagarto schon dabei ist. Dann wird halt noch der JTAG Adapter und eine Serveranwendung wie OpenOCD benötigt die zwischen JTAG und GDB vermittelt. Eine Anleitung dazu gibt es auf der Yagarto Seite ("Using OpenSource.."). Für diejenigen bei denen Zeit keine Rolle spielt und/oder alles nichts kosten darf ist OpenOCD sicher eine gute Wahl. Alle anderen sollten sich vielleicht besser nach einer kommerziellen Lösung umsehen. Ich selbst verwende seit kurzem einen J-Link mit dem GDB-Server (beides von Segger), den es (ebenfalls seit kurzem) in einer non-commercial Version gibt. Andere Server/Debugger die Eclipse unterstützen sind mir nicht bekannt, was aber nicht viel heißt.
Das "Using OpenSource.." bezieht sich leider nur auf den Atmel Chip. Beim LPC funktioniert das Debuggen nicht richtig. @Robert Teufel: können Sie ein paar Sätze zu der Info von let schreiben? Code::Blocks habe ich mal geladen und installiert. Die Oberfläche sieht einfach zu bedienen aus, der Eclipse ist jedoch deutlich besser (z.B. Auto-Vervollständigung mit Strg+Space usw.). Dieser nutzt auch den gleichen GNU-ARM Compiller und GDB wie der Eclipse. Funktioniert beim Code::Blocks das Debuggen trozdem besser als wie mit Eclipse?
Beim Debuggen sollte es doch egal sein ob auf dem Controller Atmel oder NXP steht. Beim J-Link muß man auch nur zum Flashen den Controllertyp angeben. Naja, debuggen kann ich mit OpenOCD und einem Olimex Nachbau zwar. Allerdings ist das sehr unzuverlässig. Ob es am Server, am Adapter oder an mir liegt habe ich noch nicht herausgefunden. Flashen ist mir noch nicht gelungen. Der J-Link mit GDB-Server kostet in der non-commercial Version alles in allem 130€. Du mußt ein Bestellformular per EMail anfordern, das unterschrieben (non-commercial) zurückeschickt/gefaxt werden muß. Die Software gibts auf der Homepage und kann so runtergeladen werden. In dem Paket ist sind zwei .pdf Dokumente für J-Link und GDB-Server enthalten die du dir vorab ansehen kannst. Aber für den J-Link bitte nicht das aktuelle (3.78) stable release benutzen. Da stürzt der Server beim Flashen ab. Es gibt da auch aktuellere beta Versionen bei denen auch die Doku aktualisiert wurde. Hier mal eine kleine Debug-Session an der Konsole. Der JTAG Stecker wurde im laufenden Betrieb eingesteckt:
1 | C:\workspace\OpenKeyer_v2\openkeyer\armkeyer_v3>arm-elf-gdb -q |
2 | (gdb) file armkeyer_v3.elf |
3 | Reading symbols from C:\workspace\OpenKeyer_v2\openkeyer\armkeyer_v3/armkeyer_v3 |
4 | .elf...done. |
5 | (gdb) target remote localhost:2331 |
6 | Remote debugging using localhost:2331 |
7 | 0x000007c8 in elapsedTime (prevTime=149265023) at Common/src/timer.c:67 |
8 | 67 if (ret == 0) ret = 1; |
9 | (gdb) monitor speed auto |
10 | Select auto JTAG speed (65535 kHz) |
11 | (gdb) l |
12 | 62 timer_t currentTimer() |
13 | 63 { |
14 | 64 timer_t ret; |
15 | 65 |
16 | 66 ret = T0TC; |
17 | 67 if (ret == 0) ret = 1; |
18 | 68 |
19 | 69 return ret; |
20 | 70 } |
21 | 71 |
22 | (gdb) p sau8GlblFont |
23 | $1 = (const uint8_t *) 0x20da "0\226\n\020 `" |
24 | (gdb) monitor go |
25 | (gdb) quit |
26 | The program is running. Exit anyway? (y or n) y |
27 | |
28 | C:\workspace\OpenKeyer_v2\openkeyer\armkeyer_v3> |
Durch das 'monitor go' läuft das Programm normal weiter. Auch nach Beenden des GDB. Screenshots vom Zylin Plugin kennst du wahrscheinlich. In Eclipse wird dann der Inhalt einer Variablen angezeigt wenn man mit dem Mauszeiger drüberfährt. Aber das hat nichts mit dem J-Link zu tun und geht auch mit OpenOCD/Wiggler.
Mit dem OpenOCD konnte ich schon flashen und debuggen, aber nur kleine Projekte (Blink-LED) sobald das ewas größer wird (nur 16 KB Programm) dann geht das nicht mehr. An Ihnen liegt es sicher nicht, wenn es manchmal geht, dann liegt es nur an der Software. Die aktuelle OpenOCD Software stürzt sogar beim Start der Debug-Session mit einer Speicherzugriffsverletzung ab und das wars dann. Also die OpenOCD Entwickler sind, glaube ich, gerade dabei ARM11 Core zu implementieren, dabei bleibt der Rest auf der Strecke. Bis der OpenOCD richtig funktioniert wird es wohl noch ein paar Jahre dauern. @let: Nur zum Verständniss, der J-Link GDB ist ein eigenständiger Server, ähnlich wie OpenOCD, den man z.B. mit Arm-Elf-GDB verbinden kann? Wenn das ganze richtig funktioniert, dann sind 130 EUR in Ordnung.
Genau, der J-Link ist der Adapter und der GDB-Server eine Art OpenOCD. Nur das der Server keine .cfg Datei braucht. Zum Flashen muß man im GDB die Flashfunktion freigeben, den Controllertyp einstellen und die Interrupt-Vektoren umbiegen. Ein vollständiges GDB Script zum Flashen sieht für den LPC so aus:
1 | file main.elf |
2 | target remote localhost:2331 |
3 | monitor endian little |
4 | monitor speed auto |
5 | monitor reset |
6 | monitor flash download = 1 |
7 | monitor flash device = LPC2378 |
8 | monitor long 0xE01FC040 = 1 |
9 | load |
10 | monitor reset |
11 | monitor go |
Am Anfang hatte ich mit dem Flashen so meine Probleme da das ganze nicht besonders gut dokumentiert war und aufgrud fehlender Prüfsummenberechnung auch nicht richtig funktioniert hat. Das hat Segger dann innerhalb von wenigen Tagen nachgezogen. Offenbar war ich der erste Kunde der den GDB-Server zum Flashen eines LPCs benutzt. Jetzt bin ich mit dem Teil sehr zufrieden. Ich sollte allerdings dabei erwähnen das ich JTAG insgesamt noch nicht lange verwende. Und meistens flashe ich damit auch nur.
Vielen Dank für die Info! Ich nutze den LPC2368 und muss den Code nach compillieren flashen und anschließend im Flash debuggen. Der LPC2368 hat nur internen Flash / RAM. Da ich den RAM für anderes verwende bleibt also nur debuggen aus dem Flash übrig. Wenn das alles mit dem JLink/GDB funktioniert, dann steht wohl eindeutig fest dass der OpenOCD eine Spassbremse ist.
Bei mir läuft auch immer alles im Flash. Der ARM7 unterstützt leider nur 2 Breakpoints. Und einer davon wird vom GDB für die 'next' Anweisung benutzt. Bleibt also in der Praxis nur noch einer übrig. In Eclipse kann man aber BReakpoints auch bequem inaktiv setzen, sodaß dann immer nur ein Brechpunkt benutzt wird. Segger bietet für den Server auch eine Erweiterung an mit der beliebig viele Bkpts gesetzt werden können. Auf der Homepage von denen steht irgendwo wie die das machen. Dieses Feature lassen die sich aber mit 400€ (netto) bezahlen. Naja, muß man ja nicht kaufen.
Ich habe gerade mal versucht den OCDRemote zu installieren, aber der möchte erst mal einen Lizenz Code haben den ich per Mail erhalte. 400 EUR sind in jedem Fall zu viel für mich.
@let: wow, super, klasse, es geht auf Anhieb !!! Ich habe einen Segger J-Link organisieren können, leihweise... Nun geht das ganze mit Yagarto, Eclipse und Arm-Elf-GDB. Ich bin mir jetzt sicher, dass OpenOCD noch ein riesiges Problem hat. Wird wohl noch eine weile dauern bis das einigermassen funktioniert... (und Sie und ich haben den OpenOCD garantiert nicht falsch parametriert.) Ich habe den Script ein wenig angepasst:
1 | target remote localhost:2331 |
2 | monitor endian little |
3 | monitor speed auto |
4 | monitor reset |
5 | monitor flash download = 1 |
6 | monitor flash device = LPC2366 |
7 | monitor long 0xE01FC040 = 2 |
8 | load |
9 | monitor reset |
"file main.elf" braucht der Eclipse nicht, das ist schon in der Debug-Einstellung drin. Bei "monitor long 0xE01FC040 = 2" setze ich die Interrupt-Vektoren in den Flash-Bereich (im RAM steht ja noch nichts). Ohne "monitor go" am Ende startet zwar der Prozessor nicht sofort und man muss den über Eclipse starten, dafür sind aber auch meine Bkpts sofort aktiv. Der "monitor go" startet die CPU aber davon weis der Arm-Elf-GDB nichts. Ich habe die Yagarto Version "yagarto-bu-2.18_gcc-4.2.2-c-c++_nl-1.16.0_gdb-6.7.1_20080201.exe", die Yagarto IDE "yagarto-ide-20071227-setup.exe", die Tools "yagarto-tools-20070303-setup.exe" und die Segger Version "Setup_JLinkARM_V379z03.exe" (beta) Ich teste ein wenig übers WoEnde und poste wenn's probleme gibt.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.