Forum: Mikrocontroller und Digitale Elektronik Kann man den LPC23xx mit Eclipse debuggen?


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


Lesenswert?

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

von lhi (Gast)


Lesenswert?

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 ?

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


Lesenswert?

Ich bin eine kleine Ein-Mann-Firma, und diese auch nur nebenberuflich.
Das ist eher ein Hobby von mir.

von lhi (Gast)


Lesenswert?

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.

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


Lesenswert?

Was für einen Debugger / Umgebung nutzt Du?

von lhi (Gast)


Lesenswert?

Bin in der glücklichen Lage mir bei Bedarf einen Lauterbach ICD
ausleihen zu können.

Compiler wie gesagt GNUARM unter Eclipse_EU.

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


Lesenswert?

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).

von Mike (Gast)


Lesenswert?

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

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


Lesenswert?

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?

von Microman (Gast)


Lesenswert?

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

von Dirk (Gast)


Lesenswert?

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.

von let (Gast)


Lesenswert?

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.

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


Lesenswert?

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?

von let (Gast)


Lesenswert?

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.

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


Lesenswert?

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.

von let (Gast)


Lesenswert?

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.

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


Lesenswert?

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.

von let (Gast)


Lesenswert?

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.

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


Lesenswert?

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.

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


Lesenswert?

@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
Noch kein Account? Hier anmelden.