Forum: Mikrocontroller und Digitale Elektronik ARM-USB-OCD + Eclipse + embeddedice_read_reg_w_check(): 1


von Michael S (Gast)


Lesenswert?

Hallo, jetzt habe ich mir schon 2 Nächte um die Ohren geschlagen, und 
ich beckomme dieses sc*** Ding einfach nicht zum Laufen...
Arbeite mit dem LPC2129 Dev Board hier aus dem Shop, sowie mit dem Arm 
Usb Adapter aus dem Shop.

Kann bitte mal jemand meine Dateien durchsehen und mir sagen, ob ich da 
irgendwas übersehe?

Als Debugeinstellungen verwende ich :
c/c++ Application: main.elf

Debugger: C:\GCCFD\GNUARM\bin\arm-elf-gdb.exe

Commands:
target remote localhost:3333
monitor soft_reset_halt
monitor arm7_9 force_hw_bkpts enable
symbol-file main.elf
thbreak main
continue

Wenn ich auf debug gehe, bleibt der Prozess ständig an der Zeile
"Debug:   embeddedice.c:157 embeddedice_read_reg_w_check(): 1"
hängen...

Oft ist es nichtmal möglich openocd korrekt zu starten.(Dann kommt auch 
obrige Meldung...)

Es wäre klasse wenn sich das mal jemand ansehen könnte, der sich mit 
openocd auskennt, oder mir jemand eine definitif funktionierende 
Konfiguration/Demoprojekt für einen lpc2129 zur Verfügung stellen 
könnte, bin langsam am Verzweifeln.

openocd Version: openocd-2006re100
OS: WinXP Sp2
Eclipse: 3.2.1

Vielen Dank im Vorraus
Michael

von Frank G. (pancho)


Lesenswert?

1. Deine openOCD Config herzeigen
2. Ein Tipp ins Dunkle: JTAG-Geschwindigkeit ist zu hoch, da sollte es 
einen Parameter JTAG_Speed oder so ähnlich geben, mit dem man das 
drosseln kann. (Bin davon leider verschont, da Wiggler-geplagt)
3. Lass mal eclipse weg und versuch es direkt mit gdb. Ein "target 
remote localhost:3333" gefolgt von "load" sollte ausreichen, um die 
Verbindung zu testen. Das Programm sollte natürlich so gelinkt sein, 
dass die Daten im Ram landen.

von Michael S (Gast)


Angehängte Dateien:

Lesenswert?

Hi,
danke für die flotte Antwort...
hatte eigentlich das Zip oben schon angehängt... scheint irgendwie nicht 
geklappt zu haben..

von Michael S (Gast)


Lesenswert?

Keiner hat eine Idee?? Habe mir gerade die dritte Nacht, ohne Erfolg, 
verschafft...

von Christian G. (Gast)


Lesenswert?

Versuchs mal im OpenOCD-Forum, da kann dir eher einer helfen. Und 
Dominic, der Autor von OpenOCD, schaut da häufiger vorbei als hier. 
Bevor du gar nicht mehr schläfst....

http://www.sparkfun.com/cgi-bin/phpbb/viewforum.php?f=18

von Dominic R. (dominic)


Lesenswert?

Hi,

sorry, dass ich den Thread nicht schon eher bemerkt habe.

Was genau funktioniert denn nicht? Die Meldung ist eine Debug-Ausgabe, 
dass der OpenOCD das Embedded-ICE Register 1 (Debug Status) liest - das 
macht er solange, bis etwas passiert, ist also vollkommen normal.

Dein Logfile zeigt, dass eine GDB Session connected, die oben von dir 
beschriebenen Kommandos ausführt und anschliessend das Target resumed.
soft_reset_halt führt Code ab Addresse 0x0 aus, und sofern der Code, der 
im Flash liegt, sich nicht in's RAM relocated wird er eben solange 
ausgeführt, bis du mit <Ctrl>-<C> (oder wie auch immer Eclipse das 
realisiert) die Ausführung unterbrichst.

Was versuchst du denn im Moment zu erreichen? Deine Anwendung scheint 
für's RAM kompiliert zu sein (thbreak main setzt einen Breakpoint im 
RAM), du versäumst aber, deine Anwendung auch in's RAM zu laden. Probier 
mal ein "load" vor dem "thbreak main".

Gruss,

Dominic

von Michael S (Gast)


Angehängte Dateien:

Lesenswert?

Hi Dominic, danke für deine Antwort, hatte die Hoffnung schon fast 
aufgegeben. Ich will meine Applikation in den LPC2129 laden (RAM) und 
dort ausführen. Der erste Breakpoint soll immer beim Einsprung in Main 
erfolgen.

In der Zwischenzeit habe ich festgestellt, dass meine *.script Datei 
nicht ausgeführt wird. Anscheinend wird der Reset-Event nicht bei target 
arm7tdmi little run_and_halt 0 arm7tdmi-s_r4 ausgeführt, deshalb habe 
ich das in run_and_init geändert. Das script wird nun angesprungen.


Aus dem Linkerscript habe ich meine Workingarea und das Ziel zum Laden 
herausgenommen, scheint bei 0x40000000 Länge 0x00004000 zu sein.
Das habe ich nun als Working Area und im *.script als load_binary 
main.bin 0x40000000

Allerdings scheint der code nicht richtig geladen zu werden, das 
entnehme ich der Zeile:
Error:   arm7_9_common.c:1936 arm7_9_write_memory(): memory write caused 
data abort

Nachdem die cfg und script -Dateien abgearbeitet wurden scheint OCD 
wieder das oben erwähnte Verhalten zu zeigen...
Debug:   embeddedice.c:157 embeddedice_read_reg_w_check(): 1


Connecte ich mich jetzt mit dem Debugger aus Eclipse heraus mit:
target remote localhost:3333
monitor soft_reset_halt
monitor arm7_9 force_hw_bkpts enable
symbol-file main.elf
thbreak main
continue

tut sich nichts. Erwartet hätte ich, dass in der Debugperspektive der 
Debugger irgendwo am Anfang von Main mit einem blauen Balken im Code 
stehenbleibt.

Sicher bin ich mir auch nicht, ob ich die richtigen Adressen zum Laden 
der Bin Datei angebe, bzw. die Working Area. Bin bei LPC2129 und OpenOCD 
neu...habe bisher immer mit einem JTAGICE und AtmelM16 gearbeitet...

Anbei nochmal die Dateien, mit denen ich momentan arbeite...

Vorgang den die Log beschreibt:
-OpenOCD starten
-ein bisschen warten
-Debugger starten
-warten
-Debugger schließen
-OpenOCD schließen

Danke für deinen Beistand
Michael

von Dominic R. (dominic)


Lesenswert?

Hallo Michael,

deine main.bin hat ~50kB, der LPC2129 aber nur 16kB RAM - du wirst deine 
Anwendung nie im RAM debuggen können. Du solltest deine Anwendung im 
Flash linken lassen, und mit flash write 0 filename 0x0 in's Flash 
schreiben lassen (flash bank in der .cfg definieren).

Zum Thema working_area / RAM: Die working_area wird vom OpenOCD zum 
Flashen und für beschleunigte Downloads benutzt. Wenn du Code im RAM 
debuggen möchtest würde ich die working_area komplett weg lassen, oder 
nur einen sehr kleinen Teil am Ende der 16kB verwenden (etwa 1kB sollte 
reichen, z.B. working_area 0 0x40003c00 0x400 nobackup). Dieser Bereich 
darf dann von deinem Image nicht benutzt werden (wohl aber von der 
Applikation z.B. als Stack).

Wenn du im RAM debuggen willst würde ich nicht erst das ELF image in 
eine .bin umwandeln, sondern direkt das ELF Image mit GDB laden lassen - 
wie das mit Eclipse geht weiss ich leider nicht.

Gruss,

Dominic

von Michael S (Gast)


Lesenswert?

Ich scheine die bin Datei falsch erzeugt zu haben... im Makefile stand:
$(OBJCOPY)  main.elf main.bin
wenn ich allerdings
$(OBJCOPY) -O $(FORMAT) main.elf main.bin
benutze sind es nur 5k...sollte demnach eigentlich im RAM gehen..habe 
das Erzeugen jetzt mal ganz rausgenommen, genauso wie das working_area.

Gibt es eine Dokumentation zu den Befehlen, die in einer *.script Datei 
verwendet werden dürfen?


Habe es wie du gemeint hast, im Startscript vom gdb gemacht, und es 
scheint zu funktionieren..
Danke dir schonmal für deine Bemühungen.

Gruss
Michael

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.