Kenne mich mit Makefiles nicht aus und wollte mein AT91SAM7X-EK-board
mit cmd " openocd-pp.exe -f sam7x_pp.cfg " flashen,
es kommt aber nur die Meldung:
"Info: jtag.c:1304 jtag_examine_chain(): JTAG device found: 0x3f0f0f0f
(Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)"
Und dann stoppt OCD.

Mein sam7x_pp.cfg sieht so aus (wo/wie wird eigentlich das binary
angegeben?):

telnet_port 4444
gdb_port 3333
gdb_memory_map enable
gdb_flash_program enable
interface parport
parport_port 0xDD00 #my printerport is on DD00, that's ok
parport_cable wiggler
jtag_speed 0
jtag_nsrst_delay 200
jtag_ntrst_delay 200
reset_config srst_only
target arm7tdmi little reset_halt 0 arm7tdmi
daemon_startup reset
jtag_device 4 0x1 0xf 0xe
working_area 0 0x00200000 0x4000 nobackup
flash bank at91sam7 0 0 0 0 0

Kann das irgend jemand korrigieren, so das es auch flasht ?
Danke schon mal für jedwede Hilfe!

> Und dann stoppt OCD.
Das ist so wohl auch o.k.

Ich kenne die neuesten Entwicklungen bei OpenOCD nicht im Detail aber
meine "übliche" Vorgehensweise ist, dass in der cfg-Datei bei target
statt reset_halt run_and_init bzw. reset_init angegeben wird. Damit
"stoppt" der Controller nicht einfach und wartet auf weitere
Anweisungen, sondern führt - falls angegeben - das Reset-Script aus.
Dieses Script ist eine Art "Batch-Datei" mit Befehlen zum Flashen, wie
man sie auch über das Telnet-Interface eingeben würde (evtl. noch ein
paar warte-Anweisungen dazu). Die letzte Anweisung im Script ist eine
"shutdown", mit dem OpenOCD beendet wird. Langer Rede, hier habe ich das
etwas beschrieben:

http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...

Man beachte, dass meine Erklärungen auf der Seite sich nicht auf die
aktuelleste OpenOCD- Version beziehen (leider im Moment zu wenig Zeit,
die Seite mit getesteten Beispielen zu aktualisieren). Bei neueren
Versionen von OpenOCD siehe Dokumentation zu flash write_image und auch
zur sehr schicken Erweiterung flash auto_erase.

Das ist in jedem Fall ein guter Artikel.
Damit Du weißt ob diese einzelnen Befehle noch funktinoieren kannst Du
die einzeln ausführen indem Du eine Telnet Verbindung zum OpenOCD
aufbaust und die einzelnen Zeilen einfach eintippst.

Das scheint ja unvorstellbar schwierig zu sein, ein paar Daten in's
Flash zu schreiben...
Rufe jetzt aus dem makefile openocd_go_flash.cmd mit folgendem Inhalt
auf:

call openocd_install_info.cmd
set OOCD_EXE=%OOCD_BIN_PP%
set OOCD_CFG=openocd_at91sam7s_flash_wiggler.cfg
%OOCD_EXE% %OOCD_DBG% -f %OOCD_CFG%

mein openocd_install_info.cmd sieht dabei so aus:

set OOCD_INSTALLDIR=C:\Programme\openocd-r423\bin
set OOCD_BIN_PP=%OOCD_INSTALLDIR%\openocd-pp.exe
set OOCD_INTERFACE=PP

und als Ausgabe erhalte ich :

Open On-Chip Debugger (2008-03-01 20:00 CET) svn: 423
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk $
Info:    jtag.c:1304 jtag_examine_chain(): JTAG device found: 0x3f0f0f0f
(Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
Info:    target.c:239 target_init_handler(): executing reset script
'openocd_at91sam7s_flash.script'
Warning: arm7_9_common.c:964 arm7_9_halt(): target was already halted
Info:    options.c:50 configuration_output_handler(): dcc downloads are
enabled
User:    target.c:766 target_arch_state(): target state: halted
User:    armv4_5.c:340 armv4_5_arch_state(): target halted in ARM state
due to debug request, current mode: Supervisor
cpsr: 0x20000053 pc: 0x00101460
Info:    options.c:50 configuration_output_handler(): flash 'at91sam7'
found at 0x00100000
Info:    options.c:50 configuration_output_handler(): Command write not
found
Warning: arm7_9_common.c:964 arm7_9_halt(): target was already halted

Was muß ich denn jetzt noch ändern, damit auch wirklich etwas in's Flash
geschrieben wird ???

Vergaß noch das openocd_at91sam7s_flash_wiggler.cfg anzugeben:

# Flash AT91SAM7S memory using openocd
# and a Wiggler-type JTAG-interface
# created by Martin Thomas
# based on information from Dominic Rath
#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface parport
parport_port 0xDD00
parport_cable wiggler
jtag_speed 0

#use combined on interfaces or targets that can't set TRST/SRST
separately
reset_config srst_only srst_pulls_trst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe

#target configuration
daemon_startup reset

#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
target arm7tdmi little run_and_init 0 arm7tdmi
run_and_halt_time 0 30

# flash-options AT91
target_script 0 reset openocd_at91sam7s_flash.script
working_area 0 0x00200000 0x4000 nobackup
flash bank at91sam7 0 0 0 0 0

# Information:
# erase command (telnet-interface) for complete flash:
# flash erase <num> 0 numlockbits-1 (can be seen from output of flash
info 0)
# SAM7S64 with 16 lockbits and bank 0: flash erase 0 0 15
# set/clear NVM-Bits:
# at91sam7 gpnvm <num> <bit> <set|clear>
# disable locking from SAM-BA
# flash protect 0 0 1 off

# For more information about the configuration files, take a look at:
# http://openfacts.berlios.de/index-en.phtml?title=O...
#----------------------------------------------------

und dann noch das openocd_at91sam7s_flash.script :

# The following commands will be executed on
# reset (because of run_and_init in the config-file)
# - halt target
# - init ecr
# - flash content of file main.bin into target-memory
# - shutdown openocd
# created by Martin Thomas
# http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects
# based on information from Dominic Rath

halt
sleep 10

# Init - taken form the script openocd_at91sam7_ecr.script
mww 0xfffffd44 0x00008000  # disable watchdog
mww 0xfffffd08 0xa5000001  # enable user reset
mww 0xfffffc20 0x00000601  # CKGR_MOR : enable the main oscillator
sleep 10
mww 0xfffffc2c 0x00481c0e   # CKGR_PLLR: 96.1097 MHz
sleep 10
mww 0xfffffc30 0x00000007  # PMC_MCKR : MCK = PLL / 2 ~= 48 MHz
sleep 10
mww 0xffffff60 0x003c0100  # MC_FMR: flash mode (FWS=1,FMCN=60)
# arm7_9 force_hw_bkpts enable  # program resides in flash

# AT91SAM7 flash command-"batch"
# adapted by Martin Thomas based on information from Dominic Rath -
Thanks
arm7_9 dcc_downloads enable
sleep 10
poll
flash probe 0
flash write 0 main.bin 0x0
# flash write is deprecated but still available.
# Update to flash write_binary 0 main.bin 0x0
reset run
sleep 10
shutdown
#----------------------------------------------------

Antwort mit jetzt auch aktualisiertem main.bin ist:

C:\Programme\openocd-r423\bin\openocd-pp.exe  -f
openocd_at91sam7s_flash_wiggler.cfg
Open On-Chip Debugger (2008-03-01 20:00 CET) svn: 423
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk $
Info:    jtag.c:1304 jtag_examine_chain(): JTAG device found: 0x3f0f0f0f
(Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
Info:    target.c:239 target_init_handler(): executing reset script
'openocd_at91sam7s_flash.script'
Warning: arm7_9_common.c:964 arm7_9_halt(): target was already halted
Info:    options.c:50 configuration_output_handler(): dcc downloads are
enabled
User:    target.c:766 target_arch_state(): target state: halted
User:    armv4_5.c:340 armv4_5_arch_state(): target halted in ARM state
due to debug request, current mode: Supervisor
cpsr: 0x80000053 pc: 0x00100ab4
Info:    options.c:50 configuration_output_handler(): flash 'at91sam7'
found at 0x00100000
Info:    options.c:50 configuration_output_handler(): Command write not
found

Es ist zum ... Zwar gibt es im neuen OCD kein "flash write" mehr,
sondern nur ein "flash write_binary" aber auch das funktioniert nicht:

Info:    options.c:50 configuration_output_handler(): Command
write_binary not found

Das mit den Problemen ist ganz einfach. Es geht nicht.

Siehe meine Threads:

Beitrag "Debuggen von LPC2368 mit Eclipse und OpenOCD?"

Beitrag "Kann man den LPC23xx mit Eclipse debuggen?"

Also ich habe mich mit dem OpenOCD auseinander gesetzt und bin zum
Schluss gekommen damit noch ein Jahr zu warten. Denn es geht einfach
nicht.

--------------------------
Freeware = Es geht was, aber nicht alles, und auch nur manchmal korrekt,
man könnte meinen es geht, stellt aber fest dass es Parametrierung sein
könnte, probiert alles aus, und geht aber immer noch nicht.

Proc Proc wrote:
> Es ist zum ... Zwar gibt es im neuen OCD kein "flash write" mehr,
> sondern nur ein "flash write_binary" aber auch das funktioniert nicht:
>
> Info:    options.c:50 configuration_output_handler(): Command
> write_binary not found
Auch flash write_binary wurde wohl inzwischen "entsorgt". In letzter
Zeit wurde an OpenOCD einiges an "Ballast" entsorgt. Man schaue in die
Dokumentation der verwendete Version insbes. zu flash write_image (s.o.)
(z.B. flash write_image main.bin 0 bin). Man verfolge den Vorschlag, die
Befehle einzeln über das telnet-interface inzugeben und zu schauen, was
ausgegeben wird (im Telnet-Fenster und im OpenOCD-Fenster). Man nutze
die erweiterte Ausgabe (-d Option).

Markus Müller wrote:
> Das mit den Problemen ist ganz einfach. Es geht nicht.
Ah ja.

> Siehe meine Threads:
> Beitrag "Debuggen von LPC2368 mit Eclipse und OpenOCD?"
> Beitrag "Kann man den LPC23xx mit Eclipse debuggen?"
Eben - "meine" und zudem bezogen auf einen andere Controller-Familie. Es
soll Foren geben, in denen man nicht auf alles eine "Lösung" erhält. Was
brachten Fehlerberichte im Sparkfun OpenOCD-Forum oder, wenn gar nichts
anderes geht, an die OpenOCD developer-mailingliste? Versucht?

> Also ich habe mich mit dem OpenOCD auseinander gesetzt und bin zum
> Schluss gekommen damit noch ein Jahr zu warten. Denn es geht einfach
> nicht.
Ah ja. Vielleicht hakelt es bei den LPC23xx/24xx noch etwas, danach
wurde aber nicht gefragt. Aber Verallgemeinerungen sind ja immer sehr
nützlich und überaus hilfreich.

> Freeware = Es geht was, aber nicht alles, und auch nur manchmal korrekt,
> man könnte meinen es geht, stellt aber fest dass es Parametrierung sein
> könnte, probiert alles aus, und geht aber immer noch nicht.
Ah ja. Verallgemeinerungen etc. etc.

>Also ich habe mich mit dem OpenOCD auseinander gesetzt und bin zum
>Schluss gekommen damit noch ein Jahr zu warten. Denn es geht einfach
>nicht.
geht's vielleicht noch ein bischen allgemeiner?
anstatt hier rum zu maulen könntest du ja einen sinnvollen beitrag
leisten, dir mal die sourcen von openocd ansehen und die deiner meinung
nach vorhandenen fehler ausbessern. wird ja für dich kein problem sein
oder?

ich setze openocd zur programmierung div. at91sam7s in verbindung mit
arm-usb-ocd ein und bin damit hoch zufrieden.

aus meiner sicht ist openocd ein tolles projakt und allen die daran
aktiv beteiligt sind möchte ich hiermit meinen dank aussprechen!


gruss
gerhard

Sorry für meine schlechte Meinung über OpenOCD. Ich habe mich wirklich
wochenlang damit rumgeärgert, Updates ausprobiert und auch im Forum
keine Lösung gefunden.

@mt: Ich habe auch Deinen Beitrag (siehe drittes Post oben) ausdrücklich
gelobt, denn der ist wirklich gut.

Leider habe ich keine Zeit um mich durch die tausenden von Zeilen
OpenOCD durchzuwälzen, es reicht nicht nur den Code zu verstehen, ich
denke man braucht da auch Ahnung vom JTAG Protokoll. Ich möchte meinen
ARM LPC programmieren und nicht die Entwicklungsumgebung.

OpenOCD ist in den letzten Tagen deutlich gewachsen, das sehe ich auch,
vor allem gibt es besse Ausgaben auf der Console bei Fehler...
Ich habe ja geschrieben zu warten, den das OpenOCD wird einmal sehr gut
sein, auch für den LPC. Jeder der SW erstellt und diese öffentlich und
kostenlos zur Verfügung stellt hat von mir eine sehr hohe Meinung! So
auch die OpenOCD Entwickler und vor allem Hr. D. Rath.

Es ist auch so schon ein ganzes Stück Arbeit Eclipse GCC Linker makefile
*.ld *.cfg GDB usw. zu verstehen. Es hat halt nicht jeder jemanden den
man Fragen kann wie's geht. Und so muss man sich Tagelang durchgoogeln.

Daß noch niemand auf der Welt mit einem Wiggler und OCD einen Controller
geflasht hat, kann ich fast nicht glauben.
Habe jetzt "flash write_image main.bin 0 bin" ausprobiert und er meckert
wie folgt (jemand eine Idee?):

openocd-pp.exe  -f openocd_at91sam7s_flash_wiggler.cfg
Open On-Chip Debugger (2008-03-22 12:00 CET) svn: r520
URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/
Info:    jtag.c:1329 jtag_examine_chain(): JTAG device found: 0x3f0f0f0f
(Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
Warning: jtag.c:902 jtag_add_reset(): requested reset would assert trst
Info:    target.c:240 target_init_handler(): executing reset script
'openocd_at91sam7s_flash.script'
Warning: arm7_9_common.c:972 arm7_9_halt(): target was already halted
Info:    options.c:50 configuration_output_handler(): dcc downloads are
enabled
User:    target.c:784 target_arch_state(): target state: halted
User:    armv4_5.c:340 armv4_5_arch_state(): target halted in ARM state
due to debug request, current mode: Supervisor
cpsr: 0x20000053 pc: 0x001010c0
Info:    options.c:50 configuration_output_handler(): flash 'at91sam7'
found at 0x00100000
Error:   flash.c:741 get_flash_bank_by_addr(): No flash at address
0x00000000

Info:    options.c:50 configuration_output_handler(): wrote 0 byte from
file main.bin in 0.000000s (-1.#IND00 kb/s)
Warning: jtag.c:902 jtag_add_reset(): requested reset would assert trst

Ist wirklich niemand im Forum, der schon mal mit OCD und Wiggler
geflasht hat?

Vielleicht hat Markus Müller doch Recht und es geht (auch wenn die
Fachliteratur voll davon ist) wirklich nicht !??

Ich würde mich natürlich auch sehr freuen, wenn es geht.

@gerhard, Sie hatten es doch am laufen, können Sie die CFG-Dateien nicht
posten?

Vieleicht kann ich davon auch etwas für meinen LPC23xx gebrauchen...

hallo proc proc,
hast du schon mal die tipps von martin thomas (posting vom 28.03.08)
beachtet oder zumindest gelesen?

ich darf zitieren:
>Auch flash write_binary wurde wohl inzwischen "entsorgt". In letzter
>Zeit wurde an OpenOCD einiges an "Ballast" entsorgt. Man schaue in die
>Dokumentation der verwendete Version insbes. zu flash write_image (s.o.)
>(z.B. flash write_image main.bin 0 bin). Man verfolge den Vorschlag, die
>Befehle einzeln über das telnet-interface inzugeben und zu schauen, was
>ausgegeben wird (im Telnet-Fenster und im OpenOCD-Fenster). Man nutze
>die erweiterte Ausgabe (-d Option).

speziell den hinweis mit der telnet session solltest du mal verfolgen.

im anhang findest du meine batch-/cfg-/script-dateien (allerdings für
den arm-usb-ocd und für die revsion 247 von openocd)

gruss
gerhard

Hallo gerhard, werde mich wann möglich auch mal in die
Telnet-Protokollierung einarbeiten;
las aber jetzt in einem anderen Forum, daß es mit sehr alten
OCD-Versionen nach vorheriger Deinstallation der Aktuellen geht.

Hat noch irgend jemand einen Link zu einer alten OCD-Version?

hallo,
im anhang die revision 247 (binaries, doc und treiber).

gruss
gerhard

Höre gerade über ein anderes Forum, daß nur Versionen vor re129 (also
re128) funktionieren sollen...

R128 hab ich nicht, aber R82 als Setup-Paket.
Dann hab ich noch "openocd_package_197_mthomas.zip" und
"openocd-2007re231-setup-rc01.exe".
Ich lade die alte Versionen aber erst hoch wenn Sie es wünschen...

>Höre gerade über ein anderes Forum, daß nur Versionen vor re129 (also
>re128) funktionieren sollen...
dann habe wir wohl 500 at91sam7s mit einer nicht funktionierenden
openocd version programmiert, ein wunder, ein wunder!!
wo hast du den diese "weisheit" her?
was soll denn nicht funktionieren?

hast du von mir gepostete vesion schon mal getestet?

gruss
gerhard

Hallo gerhard; die 247 habe ich noch nicht getestet, habe aber heute die
Version re128 erhalten, die beim mitglied des anderen Forums (sparkfun)
garantiert mit wiggler läuft und bei mir auch nur ”Command write_binary
not found” sagt, d.h. ich mache noch irgend etwas anderes falsch und an
der Version liegt es jetzt nicht mehr.

Kenne mich mit Debuggen und ARM aber auch gar nicht aus. Hatte nur vor
Monaten mal das AVR-GCC-Package heruntergeladen, ein PP-JTAG
angestöpselt und auf "run" geklickt uns sofort war mein Programm im
Atmega8 und lief.
Alles völlig unkompliziert und in wenigen Minutn installiert!!

Beim der ARM-Umgebung dagegen ist das schon eine echte Wissenschaft und
für den PC-Laien wie mich, der eigentlich nur ein Programm in's Flash
bringen will und sich nicht mit PC-Script-Programmierung und
Debugsserverkonfigurationen herumschlagen will vielleicht gar nicht zu
schaffen!?

Aber entmutigen lasse ich mich noch nicht... ;)

im anhang findest du batch-/cfg-/script-dateien zum programmieren des
flash (allerdings für den arm-usb-ocd und für die revsion 247 von
openocd)

gruss
gerhard

P.S.: anbei meine aktuellen Scripte

hallo,
meiner meinung nach sind folgende anweisungen in
openocd_at91sam7x_flash_wiggler.cfg  in der falschen reihenfolge:

target_script 0 reset openocd_at91sam7x_flash.script
working_area 0 0x00200000 0x4000 nobackup
flash bank at91sam7 0 0 0 0 0

richtig wäre es so:

working_area 0 0x00200000 0x4000 nobackup
flash bank at91sam7 0 0 0 0 0
target_script 0 reset openocd_at91sam7x_flash.script

gruss
gerhard

Habe noch nicht nachgesehen, wo der Unterschied zwischen meinen alten
Sripten und den von mir jetzt angepaßten Scripten von gerhard liegt,
aber so wie im jetzigen Dateianhang läuft es nun !! (Danke gerhard!).

Anbei wie gesagt für die Nachwelt mit ähnlichen Problemen die Scripte.

>Habe noch nicht nachgesehen, wo der Unterschied zwischen meinen alten
>Sripten und den von mir jetzt angepaßten Scripten von gerhard liegt,
>aber so wie im jetzigen Dateianhang läuft es nun !!
die reihenfolge in der cfg-datei stimmt nun
es muß zuerst

 flash bank at91sam7 0 0 0 0 0 

ausgeführt werden und erst dann das script gestartet werden

 target_script 0 reset program.script 

diesen fehler habe ich auch hier gefunden:
http://gandalf.arubi.uni-kl.de/avr_projects/arm_pr...

und hier ist die reihenfolge richtig:
http://www.mikrocontroller.net/articles/AT91SAM7S_...

gruss
gerhard

@gerhard: Vielen Dank für R247 !!!!!

Jetzt kann ich auch meinen LPC23xx flashen und debuggen.

Einfach nur die EXE getauscht, dann gings.
R279, R320, R423, R520 funktionieren alle nicht.
(Hätte ich doch ein bischen früher mit dem ARM angefangen, dann hätte
ich mir viele Nerven geschont ... oder halt warten bis es wieder
funktioniert.)

OpenOCD war doch mal SUPER!!!

Grüße M.Müller

Das Flashen klappt ja jetzt bei mir. Würde aber im Idealfall auch
debuggen wollen und da stellt sich bei mir als Eclipse-Neuling die Frage
nach der Konfiguration.
Laut Using_Open_Source_Tools_for_AT91SAM7S_Cross_Development müßte im
Debug-Dialog eine Position "Embedded debug launch" stehen, die bei mir
fehlt.
Woher kommt die/oder weiß jemand wo es das plugin dazu gibt (wurde durch
mein yagarto offenbar nicht erzeugt)?

P.S. Offenbar heißt die "Embedded debug launch" jetzt "Zylin Embedded
debug (Native)" oder muß ich "Zylin Embedded debug (Cygwin)"  nehmen?

Und was für ein File wird bei "C/C++ Application eingegeben". ein
main.out wird bei mir mit meinen makefile-Einstellungen nicht erzeugt
(wie muß ich die dazu ändern und ist das main.out ein main.bin mit
zusätzlichen debug-Informationen oder gar ein main.elf?) ?

In meinem Thread

Beitrag "Debuggen von LPC2368 mit Eclipse und OpenOCD?"

habe ich folgenden Download hinterlegt

http://www.mikrocontroller.net/attachment/31584/82...

Darin sind einige Screenshots die für die Konfiguration nützlich sind.

... natürlich für den LPC23xx, sollte aber prinzipiell auch für Ihren
interessant sein.

Irgendwie scheint der GDB-Server nicht richtig zu laufen; Eclipse sagt:

Embedded GDB (03.04.08 16:45) (Suspended) <The program is not being
run.>
c:\Programme\yagarto\bin\arm-elf-gdb.exe (03.04.08 16:45)

Und die Konsole gibt unten stehendes aus, wobei ich natürlich nicht die
LPC2368-Kommandos nehme, sondern nach James Lynch:

target remote localhost:3333
monitor soft_reset_halt
monitor arm7_9 force_hw_bkts enable
sysmbol-file main.elf
thbreak main
continue

und erhalte:

No source file named main.elf.
target remote localhost:3333
localhost:3333: Es konnte keine Verbindung hergestellt werden, da der
Zielcomputer die Verbindung verweigerte.
monitor soft_reset_halt
"monitor" command not supported by this target.
monitor arm7_9 force_hw_bkts enable
"monitor" command not supported by this target.
sysmbol-file wps-ex_flash.elf
Undefined command: "sysmbol-file".  Try "help".
thbreak main
No hardware breakpoint support in the target.
continue
The program is not being run.
No registers.

Hast Du OpenOCD überhaupt gestartet, bevor Du arm-elf-gdb.exe startest?

> localhost:3333: Es konnte keine Verbindung hergestellt werden, da der
> Zielcomputer die Verbindung verweigerte.

Oder hat Du Ärger mit der Firewall?

Zunächst mal die Frage nachdem das Flashen jetzt geht: kann mann denn
jetzt auch tatsächlich im Flash debuggen?

Eine Firewall ist übrigens nicht aktiv.

Und noch die ganz dumme Frage: Wie starte ich openOCD denn eigentlich?
Das
Flash-Script kann ich ja nicht verwenden und ich brauche ein
Debug-Script
(hatte das Flashen bisher per batch aus dem Make gestartet, aber was
passiert vom Ablauf her, wenn ich auf
den grünen Debug-Käfer klicke? Die Initialisierung ist ja: target remote
localhost:3333;monitor soft_reset_halt;monitor arm7_9;force_hw_bkts
enable;sysmbol-file main.elf;thbreak main;continue)

Und mein Debug-Script ist zur Zeit:
interface parport
parport_port 0xDD00
parport_cable wiggler
jtag_speed 0
jtag_nsrst_delay 200
jtag_ntrst_delay 200
reset_config trst_and_srst
jtag_device 4 0x1 0xf 0xe
daemon_startup reset
target arm7tdmi little run_and_init 0 arm7tdmi_r4
working_area 0 0x20000000 0x4000 nobackup
flash bank at91sam7 0 0 0 0 0

>Zunächst mal die Frage nachdem das Flashen jetzt geht: kann mann denn
>jetzt auch tatsächlich im Flash debuggen?
guckst du hier:
http://www.yagarto.de/howto/yagarto2/index.html

gruss
gerhard

Ob "http://www.yagarto.de/howto/yagarto2/index.html"; jetzt "ja" oder
"nein" heißt, spekuliere ich wegen des dort erwähnten "these examples
are only for debugging in RAM" einmal.

Habe auf jden Fall die Einstellungen aus dem eclipse_ram.gdb dort in
Eclipse unter 'Initialize' commands' eingetragen und aus Ethernut3Test
die at91r40008_pp.cfg und reset.script an meinen µC angepaßt und jetzt
bleibt der OCD-Server auch weiter aktiv.
Beim debuggen erhalte ich dann die Meldungen:

No source file named main.elf.
target remote localhost:3333
0x001011e8 in ConfigureIO () at main.c:106
106    AT91C_BASE_PIOB->PIO_PER   = (AT91C_PIO_PB13);    // set to PIO
mode
monitor reset
monitor sleep 500
monitor poll
target state: halted
target halted in ARM state due to debug request, current mode:
Supervisor
cpsr: 0x20000053 pc: 0x00101254
monitor soft_reset_halt
requesting target halt and executing a soft reset
monitor arm7_9 sw_bkpts enable
software breakpoints enabled
monitor mww 0xFFE00000 0x1000213D
monitor mww 0xFFE00004 0x20003E3D
monitor mww 0xFFE00020 0x00000001
monitor mdw 0xFFE00000 1
0xffe00000: 00000000
monitor mdw 0xFFE00004 1
0xffe00004: 00000000
load
Loading section .text, size 0x13c8 lma 0x100000
Loading section .data, size 0x7c lma 0x1013c8
Start address 0x100000, load size 5188
Transfer rate: 9 KB/sec, 288 bytes/write.
break main
Breakpoint 2 at 0x101240: file main.c, line 118.
continue

Soweit alles ganz schön.
Nur habe ich in Zeile 118 gar keinen Breakpoint und wenn ich dort einen
hinsetze und auch auf der Zeile bleibe (blaue Linie) läuft das Programm
dennoch weiter in die Hauptschleife.
(Aber mit den Details zum Debuggen befasse ich mich dann mal in der
nächsten Woche ...)