Debuggen von LPC2368 mit Eclipse und OpenOCD?

[mmvisual (Gast)]

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

[Tilo (Gast)]

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.

[MmVisual (Gast)]

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.

[Jansus (Gast)]

Müsste es nicht heißen: monitor mww 0xE01FC040 0x0002 (RAM Mode)?

Grüße
Jansus

[mmvisual (Gast)]

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

[gast (Gast)]

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.

[gast (Gast)]

Achso die Frage war wiso dann zuerst mit Flash magic flashen.

[MmVisual (Gast)]

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.

[gast (Gast)]

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

[MmVisual (Gast)]

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 ;)

[gast (Gast)]

Jo mach ich, am Abend.

[gast (Gast)]

Hallo hier der workspace in eine Orner entpacken und Eclipse auf dem 
Workspace starten dann kanns du die die Projekt einstellungen ansehen.

viel spaß

[mmvisual (Gast)]

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 :(

[mmvisual (Gast)]

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.

[Gast (Gast)]

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!

[mmvisual (Gast)]

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.

[mmvisual (Gast)]

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 
:)

[gast (Gast)]

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

[Dominic R. (dominic)]

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

[MmVisual (Gast)]

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

[gast (Gast)]

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.

[mmvisual (Gast)]

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.

[Gast (Gast)]

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

[mmvisual (Gast)]

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.

[mmvisual (Gast)]

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?

[Dominic R. (dominic)]

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

[mmvisual (Gast)]

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

[mmvisual (Gast)]

@Dominic: Gerne kann ich für Sie OpenOCD Versionen testen, bevor Sie die 
auf yagarto veröffentlichen...

[Dominic R. (dominic)]

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

[mmvisual (Gast)]

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.

[mmvisual (Gast)]

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.

[Tilo (Gast)]

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.

[mmvisual (Gast)]

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?

[mmvisual (Gast)]

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.