Datum: 17.02.2008 23:45
Hallo, Ich mache schon seit Tagen an der Programmierumgebung herum. Ich habe den OpenOCD nun richtig zum laufen gebracht und mir Konfigurationsdateien erstellt. Das Blink-LED Programm konnte ich auch kompillieren und mit FlashMagic über serielle Schnittstelle brennen. Die LEDs blinken auch. Nun möchte ich gerne das Projekt mit Eclipse debuggen. Ich habe von http://www.yagarto.de die aktuelle IDE mit Zylin Plugin installiert. Eine Verbindung zum OpenOCD wird aufgebaut, aber debuggen geht dennoch nicht. Als Debugger habe ich den "arm-elf-gdb.exe" eingestellt. Die Debug-Konfiguration starte ich als "Zylin Embedded debug (Native)". Unter "'Initialize' Commands" habe ich folgende Einträge:
target remote localhost:3333 monitor wait_halt monitor sleep 500 monitor poll monitor soft_reset_halt monitor arm7_9 sw_bkpts disable monitor arm7_9 force_hw_bkpts enable monitor mww 0xE01FC040 0x0001 monitor mdw 0xE01FC040 monitor armv4_5 core_state thumb symbol-file test.elf break main continue |
Ich glaube da muss irgendwas falsch sein. Irgendwie klappt das Debuggen nicht. Könnt Ihr mir bitte helfen? Die Zeile "armv4_5 core_state thumb" müsste richtig sein, da ich mit der Compilleroption "-mthumb-interwork" kompilieren. Beim Setzen oder Löschen eines Breakpoints erscheint in der Console des OpenOCD folgende Meldung:
Warning: arm7_9_common.c:1922 arm7_9_read_memory(): memory read caused data abort (address: 0x2c000000, size: 0x4, count: 0x1) |
Irgendwie ist das auch nicht korrekt. Die Ausgabe auf im Console-Fenster:
No source file named test.elf. target remote localhost:3333 0x2c000000 in ?? () monitor wait_halt waiting for target halted... target halted monitor sleep 500 monitor poll target state: halted target halted in ARM state due to debug request, current mode: Undefined cpsr: 0x800000db pc: 0x0000002c monitor soft_reset_halt requesting target halt and executing a soft reset monitor arm7_9 sw_bkpts disable software breakpoints disabled monitor arm7_9 force_hw_bkpts enable force hardware breakpoints enabled monitor mww 0xE01FC040 0x0001 monitor mdw 0xE01FC040 0xe01fc040: 00000001 monitor armv4_5 core_state thumb core state: Thumb symbol-file test.elf break main Breakpoint 2 at 0x108: file src/main.c, line 100. continue |
Hier die OpenOCD Konfigurationsdatei:
telnet_port 4444 gdb_port 3333 interface ft2232 ft2232_device_desc "Olimex OpenOCD JTAG A" ft2232_layout "olimex-jtag" ft2232_vid_pid 0x15BA 0x0003 jtag_speed 12 jtag_nsrst_delay 200 jtag_ntrst_delay 200 reset_config trst_and_srst jtag_device 4 0x1 0xf 0xe target arm7tdmi big reset_halt 0 arm7tdmi-s_r4 run_and_halt_time 0 30 daemon_startup reset working_area 0 0x40000000 0x4000 nobackup flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v2 12000 calc_checksum |
... Ich habe mich schon halb tot gegoogelt um die richtigen Einstellungen zu finden, leider ohne Erfolg. Bitte helft mir. Vielen Dank für eure Hilfe im Voraus, Grüße Markus
Datum: 17.02.2008 23:54
Schau mal in deinen Dateien, ob die Adressen für SRam und Flash stimmen. Aus irgend einem Grund soll auf Speicheradressen zugegriffen werden, die es anscheinend nicht gibt.
Datum: 18.02.2008 07:35
Im Linker-Script stehen diese Adresse nicht drin:
MEMORY
{
flash : ORIGIN = 0x00000000, LENGTH = 500K
ram : ORIGIN = 0x40000000, LENGTH = 32K
usbram : ORIGIN = 0x7FD00000, LENGTH = 8K
ethram : ORIGIN = 0x7FE00000, LENGTH = 16K
}
__stack_end__ = 0x40000000 + 32K - 4; |
Im Quellcode habe ich auch keine Adresse 0x2c000000 definiert, also es ist ein einfaches Blink-Led Programm mit einer Delay als For-Schleife ohne Interrupt. Der Stack funktioniert auch, da die Delay eine separate Funktion ist. Gruß Markus.
Datum: 18.02.2008 08:23
Müsste es nicht heißen: monitor mww 0xE01FC040 0x0002 (RAM Mode)? Grüße Jansus
Datum: 18.02.2008 08:48
Eigentlich nicht, denn ich möchte im Flash debuggen. Dazu flashe ich erstmal mit FlashMagic, dann möchte ich debuggen. In den "'Initialize' Commands" gibt es daher auch nicht den Befehl "load". Der LPC2368 hat nicht so viel RAM dass ich mein Projekt im RAM debuggen kann, mein Projekt wird sicher größer werden als das jetzige Blink-LED. Diese Info habe ich von diesem Thread Beitrag "LPC2106 mit Openocd im Flash debuggen" aber bei meinem LPC2368 klappt das irgendwie nicht. Nur eines habe ich nicht gefunden:
"Damit es funktioniert muß aber in der Konfiguration des Debuggers auf der Registerkarte Debugger die Option "Start on startup at" aktiviert sein." |
Datum: 18.02.2008 13:10
Man kann doch driekt via load ins Flash laden mit OpenOCD, oder täusche ich mich da? Siehe Beispiel für LPC2148 auf Yagarto Seite.
Datum: 18.02.2008 13:11
Achso die Frage war wiso dann zuerst mit Flash magic flashen.
Datum: 18.02.2008 13:22
Ich habe das auch schon mit dem OpenODC und Telnet versucht. So konnte
ich direkt, ohne Eclipse und ARM-ELF-GDB, den Flash manipulieren.
Aber:
Das klappt nicht richtig, nur jedes Xte mal klappt es. Un wenn das
Programm dann im Flash ist kann ich die CPU über Telnet Befehle nicht
starten ("reset run" geht nicht)
Der Telnet-Befehl "flash ersae 0 0 0" sollte doch den Flash löschen.
Dann der Befehl "mdb 0 16" zeigt mir auch lauter FF an. Wenn ich die CPU
Stromlos mache und wieder aktiviere, dann sollten da immer noch FF drin
stehen, aber da erscheint wieder der alte Code (nur die CPU läuft
nicht).
Also das mit dem Flashen, Flash löschen usw. geht mit OpenOCD nicht
richtig. (Version R279 verwende ich)
Der Befehl "flash erase_check 0" lässt sogar das OpenOCD abstürzen.
Wenn das ganze über Telnet nicht richtig geht, wie soll es dann über
Eclipse und ARM-ELF-GDB über die "monitor" Befehle gehen. Daher versuche
ich die Möglichkeit von Sven Woehlbier.
Datum: 18.02.2008 13:31
Komisch also bei mir mit LPC2148 geht es mit der Version. Flash Debuggen und mit load zuerst ins Flash laden. Hoffe das es auch im Flash ist wobei, wenn ich den uC Resete läuft die Applikation auch also muss es im Flash sein oder. Kommisch ich habe auch noch eine LPC23xx ich versuchs am abend auch mal mit diesem
Datum: 18.02.2008 13:53
Kannst Du mir die Konfiguration des OpenOCD und "Commands" für den Debugger posten? Den Umweg über Flash Magic würde ich mir gerne ersparen. Eigentlich müsste sich der LPC23xx gleich verhalten, kommen ja beide von NXP ;)
Datum: 18.02.2008 14:20
Jo mach ich, am Abend.
Datum: 18.02.2008 19:36
Hallo hier der workspace in eine Orner entpacken und Eclipse auf dem Workspace starten dann kanns du die die Projekt einstellungen ansehen. viel spaß
Datum: 18.02.2008 20:50
Vielen Dank!!!! Ich hab schon einen Unterschied gesehen:
# tell gdb our flash memory map # and enable flash programming gdb_memory_map enable gdb_flash_program enable |
das stand nicht in meiner GDB Datei für den OpenOCD drin. Ich habe auch die Endian Einstellung unter "target" wieder auf "little" umgestellt. Auf anhieb möchte das Demo-Projekt nicht funktionieren, ich experimentiere noch etwas. Im Moment kämpfe ich noch mit der Debugger Meldung "No source file named test.elf.". Diese kommt als erste Zeile sobald ich den Debugger aktivieren. Gestern kam diese noch nicht :(
Datum: 18.02.2008 21:47
Ganz so einfach ist das alles nicht.... Der Debugger schreibt mir folgendes auf den Bildschirm (PP-Wiggler), der OLIMEX ist ein bischen schneller:
No source file named test.elf. target remote localhost:3333 main () at src/main.c:120 120 FIO3SET = 0x06000000; monitor reset monitor sleep 500 monitor poll target state: running monitor soft_reset_halt requesting target halt and executing a soft reset monitor arm7_9 sw_bkpts disable software breakpoints disabled monitor arm7_9 force_hw_bkpts enable force hardware breakpoints enabled monitor mww 0xE01FC040 0x0002 monitor mdw 0xE01FC040 0xe01fc040: 00000002 monitor flash erase 0 0 0 erased sectors 0 through 0 on flash bank 0 in 0s 180259us monitor flash write_image test.elf wrote 2000 byte from file test.elf in 0s 540778us (3.611695 kb/s) break main Breakpoint 1 at 0x160: file src/main.c, line 100. load Loading section startup, size 0x3c lma 0x0 Loading section prog, size 0x794 lma 0x3c Memory access error while loading section prog. continue |
Die erste Zeile kommt mir komisch vor, die Datei existiert. Der Befehl "load" schreib nicht ins Flash. Ich bekomme nur mit den Befehlen "monitor flash erase" und "monitor flash write_image" etwas in das Flash, und dann kann ich das auch debuggen.
Datum: 18.02.2008 22:02
Hi! Mich würden die GDB-Einstellungen auch brennend interessieren. Leider kann ich im geposteten Projekt keine Einstellungen entdecken. Wenn ich's mit Eclipse öffne, finde ich leider auch nix. Kann einer von Euch Beiden die Commands noch mal als einzelne Datei oder so hier ins Forum stellen? Wäre klasse!
Datum: 18.02.2008 22:18
Hier die ganze Info: - Für LPC23xx - Eclipse Version 3.3.1.1 - Arm-Elf-GCC Version 4.2.1 - Arm-Elf-GDB Version 6.5.50.20060612-cvs - OpenOCD R279 Setup-Pakete von www.yagarto.de: - yagarto-bu-2.17_gcc-4.2.1-c-c++_nl-1.15.0_gi-6.5.5_20071117.exe - yagarto-ide-20071227-setup.exe - openocd-r279-20080202.exe Zusätzlich kann von www.flashmagictool.com auch das Flash-Tool "FlashMagic.exe" verwendet werden. Das funktioniert über den COM-Port sicher und zuverlässig. (Die Reset und Boot-Pins sollten auch über den COM-Port gesteuert werden.) Die Konfig-Datei für den OpenOPC OLIMEX ARM-USB-OCD:
#daemon configuration telnet_port 4444 gdb_port 3333 # tell gdb our flash memory map # and enable flash programming gdb_memory_map enable gdb_flash_program enable #interface interface ft2232 ft2232_device_desc "Olimex OpenOCD JTAG A" ft2232_layout "olimex-jtag" ft2232_vid_pid 0x15BA 0x0003 jtag_speed 1 jtag_nsrst_delay 200 jtag_ntrst_delay 200 #use combined on interfaces or targets that can't set TRST/SRST separately reset_config trst_and_srst #jtag scan chain jtag_device 4 0x1 0xf 0xe #target configuration target arm7tdmi little reset_halt 0 arm7tdmi-s_r4 run_and_halt_time 0 30 daemon_startup reset working_area 0 0x40000000 0x4000 nobackup #flash configuration flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v2 12000 calc_checksum |
Die Konfig-Datei für den OpenOPC Parallel-Port Wiggler:
#daemon configuration telnet_port 4444 gdb_port 3333 # tell gdb our flash memory map # and enable flash programming gdb_memory_map enable gdb_flash_program enable #interface interface parport parport_port 0x378 parport_cable wiggler jtag_speed 0 jtag_nsrst_delay 200 jtag_ntrst_delay 200 #use combined on interfaces or targets that can't set TRST/SRST separately reset_config trst_and_srst #jtag scan chain jtag_device 4 0x1 0xf 0xe #target configuration target arm7tdmi little reset_halt 0 arm7tdmi-s_r4 run_and_halt_time 0 30 daemon_startup reset working_area 0 0x40000000 0x4000 nobackup #flash configuration flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v2 12000 calc_checksum |
Dateien sind für den LPC2366, der LPC2368 hat mehr Flash... Im "Open External Tools Dialog..." wird der OpenOCD Debugger angelegt, mit folgenden Einträgen:
Location: C:\WinARM\openocd\bin\openocd-pp.exe
Working Directory: ${workspace_loc:/LPC2368_MM}
Arguments: -f ${workspace_loc:/LPC2368_MM}\prj\lpc23xx_pp.cfg |
Die Debugger-Einstellung unter "'initialize' commands":
target remote localhost:3333 monitor reset monitor sleep 500 monitor poll monitor soft_reset_halt monitor arm7_9 sw_bkpts disable monitor arm7_9 force_hw_bkpts enable monitor mww 0xE01FC040 0x0002 monitor mdw 0xE01FC040 monitor flash erase 0 0 0 monitor flash write_image test.elf break main load continue |
Der "monitor flash erase" Befehl muss natürlich den zu löschenden Datenmengen angepasst werden. Wichtig: Das ganze muss unter "Zylin Embedded debug (Native)" ausgeführt werden. Der Olimex macht beim Start der Debug-Session keinen Break bei Main, warum auch immer... !?? beim PP Wiggler geht's. Dass alle Dateinamen und Pfadangaben den gegebenheiten angepasst werden müssen, bräuchte ich eigentlich nicht erwähnen. Ich danke für eure Unterstützung, Gruß Markus.
Datum: 18.02.2008 22:44
Anbei alle Konfigurationen als Download. Ich habe von den einzelnen Eclipse-Seiten, zumindest den wichtigen, Screenshots mit beigefügt. @Admin @M. Fischer @Dominic Rath Ihr könnt, eure yagarto / berlios Seite gerne mit diesen Infos erweitern :)
Datum: 19.02.2008 21:10
Bekommt ihr eigentlich auch immer warnings und so weiter? Funktionieren tut es trotzdem und auch wirklich in einer vertretbaren zeit aber kommisch sind diese trotzdem irgendwas mit memory_read etc….
Datum: 19.02.2008 21:16
Beim Zurückverfolgen der Stack Frames versucht GDB oft auf nicht definierte Bereiche zuzugreifen, was dann zu Data-Aborts führt. Der OpenOCD gibt dafür Warnings aus, die aber ignoriert werden können. @mmvisual: Ich werd Michael ne Mail schreiben, falls er deinen Post nicht schon selbst gesehen hat. Gruß, Dominic
Datum: 19.02.2008 21:37
Vielen Dank! Ich wollte euch nicht per Mail belästigen, Ihr bekommt sicher eh schon viel Spams... In den Debugger-Einstellungen habe ich nach den "monitor" Befehlen noch diese Zeile eingefügt, die ist zwar nicht wichtig, könnte aber helfen nicht zu viele BKPTS zu haben...
set remote hardware-watchpoint-limit 2 |
Gruß Markus
Datum: 22.02.2008 09:34
Hallo Zusammen, Ich habe ein Problem bei der Installation von Yagarto. Ich habe 2 Rechner, auf dem einen läut es auf dem anderen habe ich ein komisches Problem. Es fehlen die beiden Einträge siehe Bild rot markiert auf Rechner 2. Ohne diese kann man ja nicht debuggen. Auf beiden Rechnern ist dasselbe installiert. Hardware nahezu identisch, nur der eine hat ein englisches WinXP – kann das zu Probleme führen? Was kann ich machen jemand ne Idee.
Datum: 22.02.2008 16:16
Ob diese beiden Zylin Einträge sichtbar sind oder nicht kann parametriert werden. Auf dieser Seite, siehe Ihr Bild, gibt es oben wo die Tasten Add, Copy usw. sind eine Taste "Filter lauch Configurations..." (Mit der Maus drüber fahren, dann kommt dieser Hinweistext). Im Anhang habe ich eine Grafik mit der Parametrierung gelegt. Mit "Filter checked launch configuration types:" kann dann z.B. Zylin ausgeblendet werden. Wenn das nicht Hilft das Verzeichnis "Yagarto-ide" einfach löschen (vorher Zippen) und das Yagarto Version "yagarto-bu-2.17_gcc-4.2.1-c-c++_nl-1.15.0_gi-6.5.5_20071117.exe" nochmal installieren. Gru0 Markus.
Datum: 24.02.2008 15:21
Hallo Bzgl. Einträge Zylin: Achtung: mit aktuelle Java-Version downloaden. Mit Version 1.4.x gibt es Probleme, da sieht man die Einträge nicht!!! Steht eigentlich auch im Yagarto-Tutorial drin. @mmvisual: Vielen Dank für Deine Hilfe! Wieso liefert eigentlich die Console von openocd in Eclipse : " No source file named main_ram.elf. target remote localhost:3333 0x40000140 in delay (i=29211) at src/main.c:62 62 while(i--); monitor reset monitor sleep 500 monitor poll target state: halted ... .. " wieso findet openocd das file nicht? debugen funktioniert aber. Vielen Dank
Datum: 25.02.2008 07:41
Bei mir kommt diese Fehlermeldung auch, funktioniert aber dennoch. Ich gehe von einem Darstellungsproblem von Zylin aus. Vieleicht gib es von Zylin ein Update das dieses Problem behebt.
Datum: 27.02.2008 07:33
Nun ist mein Code entwas gewachsen und ich habe ständig das Problem, das ich beim Debuggen den Code nicht in den Prozessor bekommen, also zu 20-30% geht es, dann aber nur wenn ich den Prozessor Spannungslos mache und den OpenOCD neu starte. Immer wieder bringt mir der Deugger die Meldungen "No MMU present" und "Ignoring packet error, continuing..." und dann geht das Debuggen nicht. Woran kann es liegen? Irgendwie habe ich das gefühl, dass der GDB nicht lange genug auf die Rückmeldungen von OpenOCD wartet oder dass die sich nicht richtig verstehen (aber nur manchmal!). Gibt es einen Warte-Befehl der den GDB zwingt auf OpenOCD zu warten? Ebenso meldet der GDB immer wieder folgendes: "warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.)". Von welchen Link kann ich eine Arm-Elf-GDB.exe bekommen, die dieses Problem nicht mehr hat? Selbst sogar wenn ich anschließend mit Flash Magic über serielle Schnittstelle flashen möchte geht es nicht, ich muss erst die CPU Spannungslos schalten, dann kann ich flashen. Also das OpcOCD verbiegt irgendwie so den Chip, dass nicht einmal ein Reset hilft, nur ein harter Reset über Spannung !?!? Ich bin Dankbar über jeden Hinweis. Anbei die Konfigurationen und Meldungen: Version OpenOCD r320. Die Konfiguration beim Start der Debug-Session:
target remote localhost:3333 monitor reset monitor sleep 200 monitor poll monitor soft_reset_halt monitor arm7_9 sw_bkpts disable monitor arm7_9 force_hw_bkpts enable monitor mww 0xE01FC040 0x0002 monitor mdw 0xE01FC040 monitor flash erase 0 0 8 monitor flash auto_erase on monitor flash erase_check 0 monitor flash write_image main.elf set remote hardware-watchpoint-limit 2 load continue |
Folgende Medungen werden von Arm-Elf-GDB ausgegeben:
No source file named main.elf. target remote localhost:3333 warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) 0x00000040 in Undef_Handler () at ../../gcc-4.2.1/gcc/config/arm/lib1funcs.asm:662 662 ../../gcc-4.2.1/gcc/config/arm/lib1funcs.asm: No such file or directory. warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) in ../../gcc-4.2.1/gcc/config/arm/lib1funcs.asm Current language: auto; currently asm warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor reset warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor sleep 200 warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor poll target state: running warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) requesting target halt and executing a soft reset monitor soft_reset_halt warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor arm7_9 sw_bkpts disable software breakpoints disabled warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor arm7_9 force_hw_bkpts enable force hardware breakpoints enabled warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor mww 0xE01FC040 0x0002 memory write caused data abort (address: 0xe01fc040, size: 0x4, count: 0x1) error: access caused data abort, system possibly corrupted warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor mdw 0xE01FC040 0xe01fc040: 00000002 warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor flash erase 0 0 8 No MMU present warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) erased sectors 0 through 8 on flash bank 0 in 0s 200288us monitor flash auto_erase on warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor flash erase_check 0 successfully checked erase state warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) monitor flash write_image main.elf wrote 18124 byte from file main.elf in 2s 323341us (7.618003 kb/s) wrote 18124 byte from file main.elf in 2s 323341us (7.618003 kb/s) warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) set remote hardware-watchpoint-limit 2 warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) load Loading section .text, size 0x46cc lma 0x0 Memory access error while loading section .text. continue warning: (Internal error: pc 0x40 in read in psymtab, but not in symtab.) |
Folgende Medungen werden von OpenOCD ausgegeben:
Info: configuration.c:56 configuration_output_handler(): opened C:\WinARM\Projekt\LPC2368_MM\prj\lpc23xx_pp.cfg Info: jtag.c:1230 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Warning: embeddedice.c:175 embeddedice_build_reg_cache(): EmbeddedICE version 7 detected, EmbeddedICE handling might be broken User: gdb_server.c:532 gdb_output(): waiting for target halted... User: gdb_server.c:532 gdb_output(): target halted Info: server.c:67 add_connection(): accepted 'gdb' connection from 0 User: gdb_server.c:532 gdb_output(): target state: running User: gdb_server.c:532 gdb_output(): requesting target halt and executing a soft reset User: gdb_server.c:532 gdb_output(): software breakpoints disabled User: gdb_server.c:532 gdb_output(): force hardware breakpoints enabled User: gdb_server.c:532 gdb_output(): 0xe01fc040: 00000002 User: target.c:390 default_mmu(): No MMU present Error: armv4_5.c:591 armv4_5_run_algorithm(): timeout waiting for algorithm to complete, trying to halt target Warning: gdb_server.c:307 gdb_put_packet_inner(): negative reply, retrying Warning: gdb_server.c:307 gdb_put_packet_inner(): negative reply, retrying Warning: gdb_server.c:307 gdb_put_packet_inner(): negative reply, retrying Warning: arm7_9_common.c:2117 arm7_9_write_memory(): memory write caused data abort (address: 0x40000008, size: 0x4, count: 0x6) User: gdb_server.c:532 gdb_output(): erased sectors 0 through 8 on flash bank 0 in 10s 354890us Error: gdb_server.c:330 gdb_put_packet_inner(): unknown character 0x24 in reply, dropping connection Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x71 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x52 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x63 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x6d Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x64 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x2c Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x63 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x31 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x33 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x38 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x32 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x30 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x31 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x35 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x34 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x66 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x35 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x66 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x35 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x32 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x31 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x33 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x35 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x32 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x30 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x66 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x65 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x23 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x65 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Error: gdb_server.c:330 gdb_put_packet_inner(): unknown character 0x24 in reply, dropping connection Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x71 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x52 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x63 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x6d Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x64 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x2c Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x63 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x31 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x33 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x38 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x32 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x30 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x31 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x35 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x34 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x66 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x35 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x66 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x35 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x32 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x31 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x33 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x35 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x32 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x30 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x66 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x36 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x65 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x23 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x65 Warning: gdb_server.c:384 gdb_get_packet_inner(): ignoring character 0x37 Warning: gdb_server.c:374 gdb_get_packet_inner(): acknowledgment received, but no packet pending Warning: gdb_server.c:374 gdb_get_packet_inner(): acknowledgment received, but no packet pending Warning: gdb_server.c:374 gdb_get_packet_inner(): acknowledgment received, but no packet pending Warning: gdb_server.c:374 gdb_get_packet_inner(): acknowledgment received, but no packet pending Warning: gdb_server.c:374 gdb_get_packet_inner(): acknowledgment received, but no packet pending Warning: gdb_server.c:374 gdb_get_packet_inner(): acknowledgment received, but no packet pending User: gdb_server.c:532 gdb_output(): successfully checked erase state User: gdb_server.c:532 gdb_output(): wrote 18124 byte from file main.elf in 2s 113039us (8.376191 kb/s) Warning: gdb_server.c:307 gdb_put_packet_inner(): negative reply, retrying Warning: gdb_server.c:374 gdb_get_packet_inner(): acknowledgment received, but no packet pending Warning: arm7_9_common.c:2117 arm7_9_write_memory(): memory write caused data abort (address: 0x00000000, size: 0x4, count: 0x61) |
Die ganzen "ignoring character" Meldungen ergeben folgenden Sinn:
$qRcmd,666c617368206175746f5f6572617365206f6e#e7 $qRcmd,666c617368206175746f5f6572617365206f6e#e7 |
Doch was bedeuten diese, was will der Debugger von OpenOCD?
Datum: 27.02.2008 08:38
Die Probleme gehen schon viel früher los: Error: armv4_5.c:591 armv4_5_run_algorithm(): timeout waiting for algorithm to complete, trying to halt target Deine erste Aktion ist "monitor mdw 0xE01FC040" - scheinbar dauert das unverhältnismässig lang, wahrscheinlich stösst der OpenOCD dabei aber auf ein anderes Problem. Versuch doch erstmal, ob die Befehle, wenn du sie "per Hand" in einer Telnet Session eingibst, funktionieren. Bei qRcmd werden einfach die ASCII Zeichen Hex codiert: 66 = f, 6c = l, 61 = a ... (flash) Insgesamt wohl "monitor flash auto_erase on" (monitor sagt GDB, den folgenden String per qRcmd an das remote Target zu schicken). Gruß, Dominic
Datum: 27.02.2008 12:51
Auf die Idee muss man erst mal kommen, dass $qRcmd einen String als HEX Code übergibt... Ich habe die einzelnen Befehle von Hand über Telnet eingegeben:
Open On-Chip Debugger > reset > sleep 500 > poll target state: running > soft_reset_halt requesting target halt and executing a soft reset Target 0 halted target halted in ARM state due to debug request, current mode: Supervisor cpsr: 0x000000d3 pc: 0x00000000 > arm7_9 sw_bkpts disable software breakpoints disabled > arm7_9 force_hw_bkpts enable force hardware breakpoints enabled > mww 0xE01FC040 0x0002 memory write caused data abort (address: 0xe01fc040, size: 0x4, count: 0x1) error: access caused data abort, system possibly corrupted > mdw 0xE01FC040 0xe01fc040: 00000002 > flash erase 0 0 8 No MMU present erased sectors 0 through 8 on flash bank 0 in 0s 190273us > flash auto_erase on > flash erase_check 0 successfully checked erase state > flash write_image c:\main.elf wrote 18124 byte from file c:\main.elf in 2s 153096us (8.220357 kb/s) > |
in der Tat meldert er beim "mww" Befehle "system possibly corrupted" Hier die Meldungen die OpenOCD in die Console schreibet:
Info: server.c:67 add_connection(): accepted 'telnet' connection from 0 Warning: arm7_9_common.c:2117 arm7_9_write_memory(): memory write caused data abort (address: 0xe01fc040, size: 0x4, count: 0x1) User: target.c:390 default_mmu(): No MMU present |
Datum: 28.02.2008 08:21
@Dominic: Gerne kann ich für Sie OpenOCD Versionen testen, bevor Sie die auf yagarto veröffentlichen...
Datum: 28.02.2008 08:42
Danke für das Angebot, die Windows Binaries auf Yagarto.de stellt Michael Fischer zusammen (wie auch die ganze Yagarto Seite, der OpenOCD ist dort nur "Gast"). Beim OpenOCD Release-Modell wird sich in nächster Zeit onehin etwas ändern, da sich der SVN Trunk derzeit viel zu schnell ändert. Wenn es dann regelmässige Releases gibt, werden wir im Vorfeld wohl auch Betas zur Verfügung stellen. Das Memory-Abort Problem beim Zugriff auf das MEMMAP (ich denke darum geht es?) kommt mir bekannt vor. Es wird ein Abort gemeldet, obwohl tatsächlich keiner stattfand. Im Anschluss scheinen alle Kommandos ordnungsgemäß durchgelaufen zu sein - hat das geflashte Programm danach denn funktioniert? Gruß, Dominic
Datum: 28.02.2008 12:43
Ja, um diesen Fehler geht es. Nach dem Flashen funktioniert das Programm nicht, auch nicht wenn die CPU Spannungslos schalte. Die gleiche HEX-Datei mit Flash Magic funktioniert, also der Code in OK. Gruß Markus.
Datum: 28.02.2008 20:23
Heute Abend habe ich mich noch mal damit intensiv auseinander gesetzt,
im Anhang sind die Scripte für OpenOCD, ARM-ELF-GDB Verbindungsaufbau
und die jeweiligen Antworten.
Von 20 mal probieren, gelang es mir nicht zu debuggen. Nur zwei mal hat
es geklappt dass das programm drin war und nach Spannung aus/ein lief
der Prozessor.
Der "load" Befehl von ARM-ELF-GDB lädt auch nur ein Teil des programms
in den flash, da ist der OpenOCD Befehl "flash write_image" schon
besser, geht aber auch nur zu 10%. Der gesamte Code ist ca. 17KB groß
(Bin-Dateigröße) was eigentlich auch nicht so übermäßig viel ist.
Die Versionen: OpenOCD r320
Arm-Elf-GDB V6.7.1
Gibt es vieleicht noch eine andere Möglichkeit, was ich testen kann?
Im Grunde ist Yagarto schon ein echt tolles und leistungsfähiges System.
Gibt es jemand, der Eclipse mit dem LPC23xx am laufen hat?
Vielen Dank für eure Unterstützung im Voraus.
Datum: 28.02.2008 21:40
Wie lange dauert bei dir das flashen? Ich musst bei größeren Programmen vor dem flashen größerer Programme die Wartezeit mit "set remotetimeout 60" verlängern.
Datum: 29.02.2008 14:59
Das Flashen geht fix:
wrote 16484 byte from file main.elf in 1s 692433us (9.511547 kb/s) |
@Hr. Lutz: Vielen Dank für den Hinweis, ich habe den Befehl mit aufgenommen. Leider wars das noch nicht. Folgende Meldung schreibt mir der Arm-Elf-GDB:
monitor mww 0xE01FC040 0x0002 memory write caused data abort (address: 0xe01fc040, size: 0x4, count: 0x1) error: access caused data abort, system possibly corrupted |
@Hr. Lutz: welche Versionen sezten Sie ein?
Datum: 02.03.2008 00:49
Mit Spannung Aus/Ein konnte ich mit Flash-Magic auch flashen. Nun habe die die serielle Bootloader-Anbindung so modifiziert, dass Flash-Magic nicht nur den Reset Pin sondern auch den TRST Pin mit rücksetzt. Jetzt muss ich keine Spannung mehr weg nehmen, damit ich mit Flash-Magic jederzeit flashen kann, egal was das JTAG Interface vorher anstellt. Debuggen geht immer noch nicht.
Email-Benachrichtigung aktivierenAntwort schreiben
Die Angabe einer Email-Adresse ist freiwillig. Wenn Sie automatisch per Email über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
- Suchfunktion und Betreffsuche benutzen - vielleicht gibt es schon einen ähnlichen Beitrag
- Aussagekräftigen Betreff wählen
- Im Betreff angeben um welchen Controllertyp es geht (AVR, PIC, ...)
- Groß- und Kleinschreibung verwenden
- Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
- JPEG-Dateien (.jpg) nur für Fotos und Scans verwenden
- Schaltpläne, Screenshots usw. als PNG oder GIF anhängen
Formatierung (mehr Informationen...)
- [c]C-Code[/c]
- [avrasm]AVR-Assembler-Code[/avrasm]
- [pre]vorformatierter Text (z.B. Code in anderen Sprachen)[/pre]
- [math]Formel in LaTeX-Syntax[/math]
- [[Titel]] - Link zu Artikel