LPC-P2378 Olimex Board debuggen mit Yagarto und J-Link EDU

[pb (Gast)]

Hallo zusammen,

seit einigen Tagen versuche ich (leider erfolglos) einen LPC2378 auf dem 
Olimex Board mit dem J-Link EDU von Segger zu debuggen.
Zum testen habe ich zunächst das Beispielprojekt von Segger (ist bei dem 
Software und Documentation pack enthalten) für den LPC2378 genommen, das 
Makefile angepasst und wie auf der Yagarto Seite beschrieben den 
Debugger und den GDB-Server konfiguriert. Wenn ich den Debugger dann 
starte und den Prozess anhalte, sieht Eclipse so aus, wie im Screenshot.
Es wird anscheinend keine passende Codestelle gefunden. Im Disassembly 
wird auch irgendeine undefined Instruction angezeigt.

Es wäre nett, wenn mir jemand helfen kann. Bin gerade erst mit dem 
Debuggen von MCUs angefangen und hab nicht viel Ahnung davon. Im Anhang 
befindet sich das Projekt mit dem ich arbiete.

Gruß
pb

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

Lies diesen Artikel STM32

und diesen Thread:
Beitrag "STM32: Debuggen mit J-Link in Eclipse vs. gdb command line"

[pb (Gast)]

Vielen Dank, den Thread kannte ich noch nicht.
Ich habe jetzt das Plugin von Zylin installiert und dort die selben 
Einstellungen wie beim GDB Hardware Debugging gemacht (Screenshot).
Mit diesen Einstellungen funktioniert das Debuggen, aber leider nur 
einmal. Wenn ich den Code anpasse und dann "Terminate and Relaunch" 
anklicke, funktioniert das ganze System nicht mehr. Der GDB Server 
verliert die Verbindung zum Debugger und zum Jlink. Wenn ich alles 
einmal beende und das Usb-Kabel kurz entferne läuft alles wieder normal.
Im Flash Debuggen geht leider gar nicht.

Vielleicht hatte ja schonmal jemand von euch dieses Problem und kann mir 
helfen.

Vielen Dank und viele Grüße

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

Das "GDB Hardware Debugging" geht besser als der Zylin.

Wie man an den "GDB Hardware Debugging" kommt ist im Artikel STM32 
beschrieben.

[pb (Gast)]

hmm, den "GDB Hardware Debugger" habe ich ja schon nur leider 
funktioniert er nicht, wie im ersten Screenshot zu sehen ist. Ich müsste 
also wissen, wie ich den Debugger konfiguriere. Das ist im STM32 Artikel 
nicht beschrieben (oder ich habs nicht gefunden). Die Konfiguration des 
GDB Hardware debuggers, wie sie unter
http://www.yagarto.de/howto/yagarto2/index.html
beschrieben ist, scheint mit dem oben angehängten Projekt nicht zu 
funktionieren.

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

In dem Thread ist das beschrieben.
Beitrag "STM32: Debuggen mit J-Link in Eclipse vs. gdb command line"

[pb (Gast)]

Sorry, aber irgendwie komm ich da gerade nicht weiter.
Hab jetzt alles versucht, wie im Thread beschrieben. Meine letzte 
Konfiguration ist bei Init Commands:

set mem inaccessible-by-default off
target remote localhost:2331
monitor speed Auto
monitor endian little
monitor flash device = LPC2378
monitor flash breakpoints = 1
monitor flash download = 1

und bei Run:

monitor reg r13 = (0x40000000)
monitor reg pc = (0x40000004)
monitor reset
continue

Funktioniert aber gar nicht bei mir. Der arm-none-eabi-gdb stürzt dabei 
nur ab. Eigentlich müsste aber das gdb file aus dem Projekt 
funktionieren, weil es mit dem Zylin ja läuft (beim ersten mal). Was 
geht denn an dem GDB Hardware debugger genau besser als am Zylin?

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

Das mit dem Hängen bleiben und aus/einstecken müsste dann weg sein.

Kannst Du mal Screenshots aller Debug-Konfiguration-Reiter machen?

[pb (Gast)]

Hallo,

hier die Screens.

Gruß

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

Ich bin mir jetzt nicht sicher ob die Befehle für den LPC2378 gut sind:
monitor reg r13 = (0x40000000)
monitor reg pc = (0x40000004)

Der Reset braucht noch eine Zahl, z.B.
monitor reset 0

Mal das ganze für Flash Linken und nochmals versuchen.

Bei mir steht im ersten Abschnitt das drin:

target remote localhost:2331
monitor flash device = STM32F103RC
monitor flash download = 1
monitor flash breakpoints = 1
monitor speed 1000
load

Der Rest wie im Bild. (Ist halt ein STM32, sollte für den ARM7 LPC 
ähnlich sein) In der Doku vom GDB Server sind alle Befehle aufgelistet 
und man kann sich aussuchen was man noch brauchen könnte.

Schreibe bitte wenn es geht, was für Parameter nötig waren.

[pb (Gast)]

Nach stundenlanger Recherche und Fehlersuche läuft es jetzt endlich.
Ich habe das Projekt von der Yagarto Seite für das Olimexboard 2148 
(hier: http://www.yagarto.de/howto/examples/index.html)
genommen und ein neues Projekt in Eclipse dafür angelegt. Das lief 
allerdings in meiner alten Konfiguration auch nicht ohne Probleme 
(Eclipse Helios und cdt-master-7.0.1-I201009241320). Habe dann Eclipse 
Ganymede und das entsprechende CDT Plugin installiert und wieder das 
Projekt vom LPC2148 neu angelegt. Mit den Einstellungen wie in den 
Screenshots und folgendem Startup Code lässt sich dann auch der LPC2378 
auf dem Olimex Board debuggen. Nach den Datenblättern der beiden 
Prozessoren sind RAM und ROM gleich adressiert. Ich weiss allerdings 
nicht, wie sich der Debugger verhält wenn man auf andere 
Speicherbereiche zugreift (wenn das überhaupt geht).

Hier der Startup Code, wie in der gdb-Datei im Projekt:

#
# This config file was tested with J-Link GDB Server v4.10i
#


# Listening for commands on this PC's tcp port 2331
target remote localhost:2331

# Set gdb server to little endian
monitor endian little

# Set JTAG speed to adaptive
monitor speed adaptive

# Reset the chip to get to a known state.
monitor reset 0

# Setup target, remap first 64 bytes
# to the internal RAM
monitor writeu16 0xE01FC040 = 0x0002
monitor writeu16 0xE01FC040

# Setup GDB for faster downloads
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed

load
break main
continue

[Daniel (Gast)]

Interessanter Thread, werde mich über die Feiertage auch
mal mit dem Thema befassen müssen. Allerdings machen mir die
Probleme hier nicht gerade viel Mut... Schon komisch, dass
es mit Helios nicht läuft.

[pb (Gast)]

So ganz läuft es bei mir immer noch nicht. Sobald ich auf Peripherie 
zugreife (ab Adresse 0xE000 0000) reisst die Verbindung zum GDB-Server 
wieder ab und nichts geht mehr. Immerhin muss ich jetzt nicht mehr den 
Stecker vom J-Link ziehen. Server neu starten reicht aus.

Kann es sein, dass das jetz ein Problem mit meinem Linker Script ist?
Folgende Ausgabe erhalte durch objdump:

Size after:
xxx.elf  :
section            size         addr
.text             14088   1073741824
.data              1088   1073755912
.bss              17964   1073757000
.stack              524   1073775104
.ARM.attributes      48            0
.comment             17            0
.debug_aranges      992            0
.debug_pubnames    2447            0
.debug_info       21006            0
.debug_abbrev      6261            0
.debug_line        7862            0
.debug_frame       2340            0
.debug_str         4060            0
.debug_loc         6613            0
.debug_pubtypes    1534            0
.debug_ranges       224            0
Total             87068

Der Adressbereich der Peripherie wird anscheinend gar nicht gelinkt wenn 
ich die Ausgabe richtig interpretiere. Wäre nett, wenn mir jemand nen 
Tip geben könnte, was ich da genau anpassen muss um auf Peripherie 
zugreifen zu können.

Vielen Dank und viele Grüße

[Daniel (Gast)]

Nabend, schon weiter gekommen ?

[pb (Gast)]

Hallo, ich bin noch nicht weitergekommen. Die peripheriezugriffe habe 
ich einfach auskommentiert und so kann ich bequem weiter debuggen ohne 
das irgendwas abstürzt. Für meine Zwecke reicht das erstmal. Wäre aber 
natürlich schön, wenn man dieses Problem auch noch irgendwie gelöst 
bekommt.
Wie siehts denn bei dir aus? Bist du weitergekommen?