www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM-USB-OCD mit Eclipse


Autor: Bastel Fix (bastelfix)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche jetzt seit mehreren Tagen (und Nächten :(( ) den 
ARM-USB-OCD mit Eclipse zum laufen zu bekommen. Zu dem guten Stück habe 
ich von Olimex eine CD mit einer vordefinierten Eclipse Arbeitsumgebung 
bekommen.

Was mache ich falsch?

Den ARM-USB-OCD zu starten ist erstmal kein Problem:
sieht dann so aus: C:\GCCFD\openocd\bin\openocd-ftd2xx.exe

Rückmeldung von der Console:
Info:    openocd.c:82 main(): Open On-Chip Debugger (2006-10-12 18:00 
CEST)


Bis hierhin würde ich sagen: alles bestens. (o.k., ich muß das gute 
Stück mehrmals anstarten bis es sich richtig verbindet, aber dann gehts)

So, nun erfolgt also der Start vom GDB:
C:\gccfd\GNUARM\bin\arm-elf-gdb.exe

Mit denn Commands:
target remote localhost:3333
monitor sleep 500
monitor poll
monitor flash probe 0
monitor flash erase 0 0 0
monitor flash write 0 main.hex 0x0
monitor reset run
monitor sleep 500
monitor soft_reset_halt
monitor arm7_9 force_hw_bkpts enable
symbol-file main.elf
thbreak main
continue

Worauf die Console vermeldet:

(gdb) target state: halted
target halted in Thumb state due to debug request, current mode: 
Supervisor
cpsr: 0x800000f3 pc: 0x7ffffaee
flash 'lpc2000' found at 0x00000000

Dann wird auf eine andere Ausgabe umgeschaltet( Text wird rot)
(siehe Textdatei im Anhang)

Error:   arm7_9_common.c:972 arm7_9_debug_entry(): cpsr contains invalid 
mode value - communication failure


Gestartet wird im Supervisor-Mode -> bestens!
GDB angestartet und schwups ist der Mode invalid.... grr

Und nun bin ich mal mit Ringen unter den Augen gespannt auf eure 
Antworten&Idden.

Beste Grüße
Bastelfix

Autor: Bastel Fix (bastelfix)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
scheint ein Flashloader-Problem zu sein:

Folgender Test:

In DOS-Box folgendes im Projektverzeichnis gestartet:
openocd-ftd2xx.exe -f lpc2xxx_armusbocd.cfg

Meldung:
Info:    openocd.c:82 main(): Open On-Chip Debugger (2006-10-12 18:00 
CEST)

Danach INSIGHT gestartet:
- angehängte Datei main.elf geladen (Ohne Optimierung kompiliert!) 
(insight vor run.jpg)

- Breakpoints angeklickt (sind nun rote Quadrate davor)
- Target Selection ->Wie in den angehängten Dateien beschrieben das 
"Target" definiert
- Prozessor-Reset (LPC2148) durch Resetbutton

- "Run -> Connect to target" (Ausgabe siehe Anhang "Ausgabe nach Run 
Connect.jpg") Ist so ok, oder?

=> Meldung GDB -> Successfully connected

- Jetzt auf "Run -> download" geklickt - es gibt eine Fehlermeldung 
(fehler.jpg)


Die Addresse an der der Schreibfehler auftritt ist jedesmal eine andere.

Was nun?

Autor: Dominic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze Eclipse selbst nicht, aber ich vermute, dass "Run->Download" 
die normalen GDB Downloadfunktionen nutzt - diese sind nur zum Laden von 
RAM, aber nicht zum Schreiben von Flash geeignet.

Die OpenOCD Version von der Olimex CD dürfte ziemlich veraltet sein - 
bei www.yagarto.de findest du eine aktuellere Version, in ein paar Tagen 
dürfte eine neue fertig sein.

Die "cpsr contains invalid mode value" Meldung deutet auf ein JTAG 
Kommunikationsproblem hin - der Grund dafür könnte die veraltete OpenOCD 
Version sein, eine zu hohe JTAG Frequenz (-> grösseren jtag_speed 
divisor ausprobieren), oder Probleme mit dem Board Layout (um welches 
Board handelt es sich?).

Gruss,

Dominic

Autor: Bastel Fix (bastelfix)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dominic :))

"Run->Download" habe ich mit dem arm-elf-insight ausprobiert.

Die OpenOCDVersion von YAGARTO hatte ich schon benutzt -> ist vom 
(2006-10-12)

Das Boardlayout habe ich angehängt. Ein Jumper steckt auf (DEB).

Den Divisor habe ich jetzt von 2 auf 4 gesetzt.

Trotzdem bekomme ich noch den "memory write caused data abort" Fehler.

Liegt das vielleicht daran, daß ich das Programm im Flash debuggen 
möchte?
Ist dafür vielleicht die OCD-config verkehrt? (siehe vorheriges 
Posting)?

Beste Grüße
Bastelfix

Autor: Dominic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

Das Board verwendet einen 12 MHz Quarz, und sofern kein Code die interne 
PLL aktiviert wird der Core mit diesen 12 MHz laufen. Bei einem 
ARM7TDMI-S wie dem LPC2000 darf die JTAG Frequenz maximal 1/6 der Core 
Frequenz betragen - der FT2232 leistet maximal 6 MHz, jtag_speed 2 teilt 
diese durch 3, was 2 MHz ergibt - das ist zu nah am maximum von genau 2 
MHz. jtag_speed 3 sollte bereits ausreichen, mit 4 bist du auf der 
sicheren Seite.

Wenn du das Programm für das Flash gelinkt hast, musst du die Binary mit 
"flash write <bank#> <filename> <offset>" in's Flash schreiben. Wichtig 
ist auch, dass der OpenOCD mit Intel-Hex nichts anfangen kann, sondern 
"einfache" Binaries erwartet. Die GNU Toolchain bietet dafür "objcopy -O 
binary <elf-file> <bin-file>".
Dann ist kein Download mehr nötig, und du kannst den GDB einfach laufen 
lassen - evtl. vorher noch "soft_reset_halt", um wieder bei Adresse 0 zu 
beginnen. Die LPC2000 sind etwas kompliziert, da man sie nicht direkt 
aus eiem Reset heraus debuggen kann.

Gruss,

Dominic

Autor: Bastel Fix (bastelfix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Jetzt gehts!! Es lag an der bin-Datei!!

Allerdings muß ich nachdem folgenden Kommandos durchgelaufen sind:

target remote localhost:3333
monitor sleep 500
monitor poll
monitor flash probe 0
monitor flash erase 0 0 0
monitor flash write 0 main.bin 0x0
monitor reset run
monitor sleep 500
monitor soft_reset_halt
monitor arm7_9 force_hw_bkpts enable
symbol-file main.elf
thbreak main
continue

den Prozesor nochmal per Reset-Button neu starten. Dann hält das ganze 
brav bei main() an und läßt sich debuggen.

Geht der Reset auch Softwaremäßig?

Ich hatte vor continue mal "monitor soft_reset_halt" und "monitor reset 
run" probiert. Hat beides nicht geholfen...

Besten Dank!

Bastelfix

Autor: Daniel Barié (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo beisammen,

ich hatte ein ähnliches Problem, welches sich aber durch Verwendung 
einer externen Spannungsversorgung beheben ließ, d.h. die Zielschaltung 
wurde nicht aus dem ARM-USB-OCD versorgt sondern erhielt Spannung von 
einem Steckernetzteil.

Zusätzlich wurde noch der Teiler für den Takt von zwei auf vier 
verändert.
Hierbei ist zu beachten, dass die Änderung für den Takt in der 
OpenOCD-Konfigurationsdatei im Projektverzeichnis vorgenommen werden 
muss.

Gruß

Daniel

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.