hallo, habe mir den USB-JTAG-Adapter für ARM zugelegt und versuch niún mit OpenOCD r88 einen AT91SAM7S256 zu programmieren. hier meine .cfg Datei: telnet_port 4444 gdb_port 3333 #interface interface ft2232 ft2232_device_desc "Olimex OpenOCD JTAG A" ft2232_layout olimex-jtag ft2232_vid_pid 0x15ba 0x0003 jtag_speed 0 reset_config srst_only jtag_device 4 0x1 0xf 0xe daemon_startup reset target arm7tdmi little run_and_init 0 arm7tdmi_r4 working_area 0 0x40000000 0x4000 nobackup flash bank at91sam7 0 0 0 0 0 wenn ich openocd starte bekomme ich folgende Ausgabe Info: openocd.c:82 main(): Open On-Chip Debugger (2006-08-17 17:00 CEST) Warning: arm7_9_common.c:781 arm7_9_halt(): target was already halted es kommt aber kein prompt um Kommandos einzugeben. any ideas? danke im voraus gerhard
hallo nochmals, das problem mit dem fehlenden prompt hat sich gelöst, hatt vergessen das openocd nur über telnet steuerbar ist. nun habe ich das flash programmieren können, allerdings dauert dies bei ca. 64kByte fast 3 minuten. ist dies normal bzw. wie kann ich dies beschleunigen? gruss gerhard
Normal ist das nicht. Mit meinem Wiggler brauchen 8 kiB nur wenige Sekunden. Was mir immer wieder auffällt: Die working-area wird von den meisten einfach stumpf aus anderen Konfigurationen abgeschrieben. So wie sie hier zu sehen ist, könnte das vielleicht mit einem LPC funktionieren, der AT91 hat aber bei 0x40000000 definitiv kein Ram, das man verwenden könnte. Oder verstehe ich da etwas falsch? Dominic?
@frank: der parameter working_area ist "stumpf" aus dem beispiel für den at91sam7s von dieser homepage abgeschrieben (siehe http://www.mikrocontroller.net/articles/AT91SAM7S_mit_OpenOCD_programmieren), sollte also so falsch nicht sein oder? leider ist der parameter nirgendwo beschrieben. danke gerhard
Drei Minuten für 64kB Flash erscheinen mir viel zu hoch, wobei ich aber nie mit dem SAM7 arbeite. Ich werde mir den Code in at91sam7.c mal ansehen (der stammt nicht von mir selbst), ob ich irgendwo ein Bottleneck finde. Im Datasheet des AT91 steht, dass sich das SRAM an Adresse 0x200000 befindet - dann wäre das Beispiel allerdings falsch. Beim SAM7 macht das aber nur etwas aus, wenn mittels "arm7_9 dcc_downloads enable" die Verwendung des Debug Communication Channels aktiviert wird, und dann auch nur bei Zugriffen auf das RAM, nicht auf das Flash. Bei 16kB RAM (S64) würde ich allerdings auf die Verwendung des DCC verzichten. Beim Philips LPC waere eine falsche working_area tragischer, da der lpc2000.c code für alle Operationen Target RAM braucht. Der Parameter ist, wie die meisten anderen, im OpenOCD Wiki beschrieben: http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger Der Hinweis auf das Wiki findet sich auf der OpenOCD Webpage unter "Documentation" sowie in den Unterpunkten "Configuration" und "Installation". Gruesse, Dominic
@dominic: danke für deinen hiwneis auf die doku, jetzt habe ich es auch gefunden. ich werde morgen mal das ganze mit der richtigen adresse testen. die falsche working area findet sich auch auf der seite von martin thomas (http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/openocd_intro/index.html) gruss gerhard
der versuch, die working_area korrekt anzugebenhat keinen erfogl gebracht. ich habe nun mal versucht den gleicen code in einen at91sam7s64 und danach in den at9121sam7s256 zu laden. dabie habe ich festgetsellt, daß das programmieren des flash im at91sam7s64 wesentlich schneller funktioniert als beim at91sam7s256 (faktor 10). ich vermute mal, das das programmieren des at91sam7s256 bisher noch niemand ausprobiert hat und einen bug hat. kann das wer bestätigen? flash info liefert folgende ausgabe: flash info 0 #1: at91sam7 at 0x00000000, size 0x00000000, buswidth 0, chipwidth 0 at91sam7 information: cidr: 0x270d0940, arch: 0x0070, eproc: ARM7TDMI, version:0x000, flashsize: 0x00040000 master clock(estimated): 32kHz pagesize: 256, lockbits: 16 0x0000, pages in lock region: 64 securitybit: 0, nvmbits: 0x0 gruss gerhard
Hallo gerhard, das Problem hatte neulich bereits jemand beschrieben (k.a. ob hier oder in nem anderen Forum). Dein at91sam7s256 läuft mit 32kHz - da muss der Debugger auf jeden Speicherzugriff ewig warten. Ich vermute mal, dass dein s64 deutlich schneller läuft (master clock(estimated): ). Eine Möglichkeit wäre, mit mw[bhw] Kommandos per Hand die PLL zu initialisieren, und dann die mclk auf die PLL zu wechseln. Gruss, Dominic
hallo dominic, herzlichen dank für den hinweis! ich hatte total übersehen daß der master clock noch auf 32kHz lief. zufälligerweise war beim at91sam7s64 dieser richtig eingestellt und dadurch das programmieren schneller. p.s.: wäre toll wenn es entsprechende .cfg und .script dateien gäbe. gruss gerhard
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.