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