USB-JTAG-Adapter für ARM, OpenOCD

gerhard Gast #395337
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
gerhard Gast #395338
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Frank Gast #395339
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dominic R. #395341
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
gerhard Gast #395343
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dominic R. #395344
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
gerhard Gast #395345
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren