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_projects/openocd_intro/index.html#at91sam7int 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=Open+On-Chip+Debugger #---------------------------------------------------- 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:
1 | target_script 0 reset openocd_at91sam7x_flash.script |
2 | working_area 0 0x00200000 0x4000 nobackup |
3 | flash bank at91sam7 0 0 0 0 0 |
richtig wäre es so:
1 | working_area 0 0x00200000 0x4000 nobackup |
2 | flash bank at91sam7 0 0 0 0 0 |
3 | 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
1 | flash bank at91sam7 0 0 0 0 0 |
ausgeführt werden und erst dann das script gestartet werden
1 | target_script 0 reset program.script |
diesen fehler habe ich auch hier gefunden: http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/openocd_intro/index.html#at91sam7int und hier ist die reihenfolge richtig: http://www.mikrocontroller.net/articles/AT91SAM7S_mit_OpenOCD_programmieren#OpenOCD_Konfiguration 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/8218_Config.zip 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 ...)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.