mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik openOCD-USB Verzweifelung


Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich habe mir und meinen Kollegen für unsere ARM7 Spielereien den 
openOCD-USB aus dem Shop zugelegt. Zusammen mit dem AT91SAM7X-EK sollte 
er als Bastelplattform für Ideen herhalten.

Aber wir sitzen nun schon einige Tage daran, den OCD überhaupt mal ans 
laufen zu bekommen. Wir haben Win2k als System und als Entwicklungsbasis 
soll YAGARTO und Eclipse dienen.

Leider ist es nun wohl so, dass nach langen Jahren ohne bezahlbare JTAG 
Adapter die wilde Flut freier oder bezahlbarer Adapter ausgebrochen ist 
und irgendwie jeder auf die Software eines Anderen aufsetzt und alle 
irgendwie vom Wiggler abstammen. Das scheint dazu zu führen, dass man 
nicht mehr für einen Adapter eine durchgängige Installationsanleitung 
findet, sondern alles irgendwie entweder verlinkt ist ( Installation 
findest Du hier <Link>) oder einfach nicht erwähnt wird: "Nimm den 
Adapter und starte den GDB Server"
Auch hier:
http://www.mikrocontroller.net/articles/AT91SAM7S_...
wir einfach davon ausgegangen, dass man einen openOCD Adapter irgendwie 
ans laufen gebracht hat. Niemand sagt einem wie...
Es wird auch immer davon ausgegangen, dass man bereits Scripte und 
Tragets und so weiter hat, die im Paket liegen. Aber openOCD-USB 
empfihlt den openOCD, aber der einzige Treiber, der usb im Namen hat ist 
der arm_ocd_usb. Ist das der Richtige? Kann das mal jemand wo hin 
schreiben?

Ein Kollege hat lange gebastelt und erste Erfolge mit Reset und Flashen 
des SAM7 via JTAG, aber erstens hat er so viel gemacht, gelesen und 
gebastelt, dass er es nicht mehr nachvollziehen kann und zweitens läuft 
es nur in einer WinXP-VM.
Ich selbst versuche nun schon drei Tage unter Win2000 mein Glück, 
bekomme aber nur serielle Schnittstellen aber keinen JTAG.

Es beginnt alles damit, dass der Link auf der Platinenunterseite
www.embedded-projects.net/OpenOCD-USB
schon ins Leere führt.
Unter www.ic-board.de kommt man dann über den Shop doch noch auf die 
richtige Seite, aber hier ist kein Wort darüber zu finden, wie man das 
Teil so mit Treibern versorgt, dass es erkannt wird. Die FTD2XX Treiber 
von FTDI selbst scheinen ja nicht die richtigen zu sein, denn die 
Ausgabe des openocd beschwert sich darüber, dass am richtigen Chip nur 
zwei serielle zu finden sind.

Ich habe in meinem Firefox nun Millionen offene Tabs rund um OCD / 
openOCD  arm_usb_ocd  wiggler / .... und doch dreht sich alles nur im 
Kreis.

Hilfe!!!

Ulrich

Autor: Lorenz .. (lorenz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Ulrich,

Du benötigst für das OpenOCD-USB-Interface die richtigen Treiber mit den 
richtigen VIDs. Diese baust du dir besser selbst aus den neuesten 
FTDI-Treibern zusammen. Dazu musst du die .inf-Datei die im 
Treiberpackage liegt abändern. Eine gute Anleitung dazu findest du auf 
der FTDI-Website.
Die benötigte PID und VID kenne ich leider nicht. Sollte aber mit der 
MProg-Software (FTDI) aus dem Device auslesbar sein. Mit allen diesen 
Informationen änderst du die .inf nun ab und gibst dem neuen Device z.B. 
den Namen "OpenOCD-USB (Channel A)".
Damit ist Teil eins schon mal erledigt. Jetzt musst du an die 
Config-Files von OpenOCD (wird mit Yagarto installiert). Du findest 
einige Beispiel-Configs für verschiedene Prozessoren und Adapter (du 
brauchst ft2232). Such dir da die passendste File raus und lege eine 
Kopie davon an. Bei den FT2232-Optionen musst du nun noch den richtigen 
Namen deines Inferfaces angeben. Oben hatte ich "OpenOCD-USB (Channel 
A)" verwendet.
Starte dann einen OpenOCD-Server mit dieser Config und verbinde dich per 
Telnet-Client mit localhost:4444. Dort sollte dich dann der 
OpenOCD-Kommandozeilenprompt begrüßen.

Hoffe ich hab nichts vergessen und das funktioniert so bei dir. Ich habe 
das vor einer weile für einen eigenen JTAG-Adapter so gemacht.

Gruß

Lorenz

Autor: Ulrich P. (uprinz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Naja, irgendwie bin ich jetzt immer noch nicht sehr viel weiter...
Ich habe nach FTDI Anleitung die INF verändert. Ich habe die Devices 
gesplittet und jeweils die EEPROM Override Flags gelöscht. Also habe ich 
jetzt zwei weitere Devices in der USB Liste stehen:
OpenOCD-USB (Channel A) und ... (Channel B).
Aber die beiden COM-Ports sind auch immer noch da, sie heißen jetzt 
lediglich anders:
OpenOCD-USB (COM22)
OpenOCD-USB (COM23)

Ich habe dann man versucht die .cfg Files im openocd zu ändern und dort 
meine VID/PID einzutragen. (Die sind übrigens 0403/6010).
Nun taucht auf wundersame Weise plötzlich das Zeug wieder auf, was ich 
versucht habe abzuschalten:
C:\Programme\openocd-r717>openocd -f interface/OpenOCD-USB.cfg -f target/sam7x25
6.cfg
Open On-Chip Debugger (2008-06-19 19:00) svn: 717
URL: http://svn.berlios.de/svnroot/repos/openocd/trunk
Info:    options.c:50 configuration_output_handler(): Open On-Chip Debugger (200
8-06-19 19:00) svn: 717
Error:   ft2232.c:1419 ft2232_init_ftd2xx(): unable to open ftdi device: 2
Error:   ft2232.c:1434 ft2232_init_ftd2xx(): ListDevices: 2

Error:   ft2232.c:1436 ft2232_init_ftd2xx(): 0: Dual RS232 A
Error:   ft2232.c:1436 ft2232_init_ftd2xx(): 1: Dual RS232 B

Jetzt fühle ich mich dann doch ein wenig vera...schaukelt...

Laut FTDI muss man ja nur die ftdibus.inf verändern. Ich würde auch 
gerne die anderen Dateien anhängen, aber das gaeht ja nur einzeln. Wäre 
zuerst aber gut, schon mal zu wissen, ob die wenigstens stimmt.

Danke für die ersten wichtigen Hinweise und bitte verlasst mich nicht :)

Ulrich

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ulrich

hast du mal die Treiber probiert die bei oocd dabei sind?

Der jtagkey_utils sollte laut .inf Datei die VID/PID 0403/6010 
unterstützen.

Autor: Wastl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin das Gefrickel auch leid. Unter Yargartoo ist es nach viel 
probieren geglückt zu debuggen. Erstaunlich, Debuggen mit völlig 
falschen Einstellungen funktioniert! Für jedes neue Projekt sind die 
Files anzupassen, nur wie? Die Doku ließt sich gut nur hat es trotzdem 
nicht funktioniert.
Und wie kann ich mit yargartoo etwas im Flash verewigen? Alles Fragen. 
Natürlich kann man sich das irgendwo zusammensuchen aber das ist was für 
Liebhaber.
In der Zeit wo ich noch gesucht hab, hat ein Kumpel unter Crossworks 
schon allerhand programmiert.
Ich will die Leistung des OpenOCD-Autors nicht schmälern, nur als Ersatz 
für eine Umgebung wie Crossworks kann es so nicht herhalten. Wenn es für 
OpenOCd eine IDE oder ein Tool gäbe mitdem man schnell die 
Konfigurationsdateiein anpassen könnte, wäre es mit Yarg. zusammen eine 
ernste Konkurrenz.
Nur der lezte Schritt fehlt da noch.
Es muss nix tolles sein, sowas wie MFile in WinAVR reicht vollkommen.
Das ein ARM was anderes ist als ein AVR weiß ich sehr gut, nur als 
Beispiel für ein gelungenes Tool.
Ich will mich auf die Aufgabe und nicht auf das Werkzeug konzentrieren.
Mein Kumpel hat den Adapter angeschlossen, Crossworks gestartet und 
alles ging ruckzuck. Ich spiele noch mit einem 30-Tage-Key und wenn mir 
das weiterhin so gut gefällt, investier ich eben die 100€.

Ich will nicht die Leistung von Herrn Rath schmälern, der dann noch die 
Courage hat alles frei rauszugeben.
Ich will nur ein Problem aufzeigen, das viele haben und oft von Experten 
nicht ernst genommen wird.
Warum waren die Nokia-Handys am Anfang des Booms so beliebt? Weil sie 
sich gut bedienen ließen!
OpenOCD kann viel nur muss das besser nutzbar gemacht werden!

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, das Klagen hilft nicht viel, es muss laufen.

Ich habe nun das ganze noch mal auf meinem Arbeitsplatz installiert und 
bin den umgekehrten Weg gegangen:
Anstelle die .INF Dateien zu modifizieren, habe ich die .cfg Dateien 
geändert:
#daemon configuration
#interface
interface ft2232
ft2232_device_desc "Dual RS232 A"
ft2232_layout oocdlink
ft2232_vid_pid 0x0403 0x6010
jtag_speed 100
jtag_nsrst_delay 200
jtag_ntrst_delay 200
Mit der Änderung
-->ft2232_device_desc "Dual RS232 A"
und
-->ft2232_vid_pid 0x0403 0x6010
wurde der OpenOCD-USB sofort erkannt. Dann habe ich noch die Pfade ein 
wenig angepasst und ein Script irgendwoher organisiert, dass eine 
main.bin flasht:
#reset_config trst_and_srst
#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 arm7tdmi <endian> <reset mode> <chainpos> <variant>
#target arm7tdmi little run_and_halt 0 arm7tdmi_r4
target arm7tdmi little run_and_init 0 arm7tdmi_r4
run_and_halt_time 0 30

target_script 0 reset bin\scripts\sam7x256\sam7x_reset.script

working_area 0 0x00200000 0x4000 nobackup

#flash bank <driver> <base> <size> <chip_width> <bus_width>
flash bank at91sam7 0 0 0 0 0

target_script 0 reset bin\new_sam7x_flash.script
Augenscheinlich funktioniert da auch was, ich erhalte jede Menge:
Debug:   3454 66875 embeddedice.c:397 embeddedice_write_reg(): 0: 0x00000005
Debug:   3455 66875 target.c:1238 target_write_u32(): address: 0xffffff64, value: 0x5a013401
Debug:   3456 66875 embeddedice.c:397 embeddedice_write_reg(): 0: 0x00000004
Debug:   3457 66906 embeddedice.c:397 embeddedice_write_reg(): 0: 0x00000005
Debug:   3458 66906 at91sam7.c:290 at91sam7_flash_command(): Flash command: 0x5a013401, flashplane: 0, pagenumber:308
Debug:   3459 66906 arm7_9_common.c:1825 arm7_9_read_memory(): address: 0xffffff68, size: 0x00000004, count: 0x00000001
Debug:   3460 66938 target.c:1170 target_read_u32(): address: 0xffffff68, value: 0x00000001
Debug:   3461 66938 at91sam7.c:264 at91sam7_wait_status_busy(): status[0]: 0x1
Debug:   3462 66938 at91sam7.c:776 at91sam7_write(): Write flash plane:0 page number:308
Aber das ganze endet mit:
Debug:   3524 68360 target.c:411 target_process_reset(): Waiting for halted stated as approperiate
Debug:   3525 68360 target.c:425 target_process_reset(): Polling target
Debug:   3526 68375 ft2232.c:253 ft2232_speed(): 86 64 00
Debug:   3528 68375 command.c:432 command_run_line(): sleep 100
Debug:   3530 68469 command.c:432 command_run_line(): shutdown
Warning: 3531 68469 arm7_9_common.c:743 arm7_9_poll(): DBGACK set, but the target did not end up in the halted stated 1
Debug:   3533 68985 target.c:425 target_process_reset(): Polling target
User:    3534 68985 target.c:436 target_process_reset(): Timed out waiting for halt after reset
Debug:   3535 68985 ft2232.c:253 ft2232_speed(): 86 64 00
und dann passiert nix mehr. openocd ist wieder auf der Kommandozeile, 
aber der Prozessor tut nix. Das geliche Script hat in der XP-VM 
erfolgreich den Code in den Prozessor geladen und den in dem Beispiel 
verwendeten httpserv.bin aus dem Nut/OS geflasht. Bei mir startet da 
absolut nix.

Ich bin also, dank Eurer Anregungen, schon einen großen Schritt weiter, 
aber der kleine bis zum Ziel fehlt noch. Kann vielleicht jemand mal 
kommentieren, was der openocd mir in den letzten Debug-Zeilen sagen 
will? Oder vielleicht einen Hinweis, was noch fehlt?

Danke schon mal,
Ulrich

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal noch ein kleiner Nachtrag:
Ich habe den Rest des Manuals mal weiter durch gearbeitet und Eclipse 
mit dem ZylinCDB eingerichtet. Der Start in den Debug Modus klappt noch, 
aber dann endet das ganze mit:
Breakpoint 1, main () at src/main.c:69
69    DWORD a = 1;
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0
kill
Hier der Log aus der openocd console:
User:    target.c:1838 handle_soft_reset_halt_command(): requesting target halt and executing a soft reset
User:    gdb_server.c:574 gdb_output(): software breakpoints enabled
Error:   arm7_9_common.c:581 arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: c
Error:   arm7_9_common.c:581 arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 10
Warning: arm7_9_common.c:1950 arm7_9_read_memory(): memory read caused data abort (address: 0x00200134, size: 0x4, count: 0x1)
Error:   arm7_9_common.c:188 arm7_9_set_breakpoint(): Unable to set 32 bit software breakpoint at address 00200134
Irgendwie kommt der Debugger nicht mehr zurück...

Irgendeine Idee?

Danke vorab,
Ulrich

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bevor ich mit openocd + gcc + FreeRTOS + lwip gearbeitet habe, hab ich 
mich immer gefragt, warum Leute 3000 Euro für Keil uVision ausgeben, wo 
doch alles auch als Open Source verfügbar ist. Danach wusste ich es.

Für das Hobby ist es ok, da kommt es auf drei oder vier Wochen nicht an. 
Der Weg ist das Ziel.

;-)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ausnahmsweise eine vom Thema abweichende Stellungnahme zu der zuvor 
gemachten Aussage:

Ich kann Dir so nicht zustimmen, lieber ...(Gast). Ich finde, solche 
Aussagen, sollte man mit einem Namen versehen, oder sie lassen.
Aber sei es drumm. Ich habe nun schon viele Projekte auf Open-Source und 
Open-Hardware aufgesetzt. Viele dieser Projekte waren ein Erfolg.
Sicherlich funktionierten einige Dinge nicht auf Anhieb und das, weil 
sie schlecht dokumentiert waren oder chaotisch programmiert.

Aber: Ich / wir haben enorm viel dabei gelernt, und zieht man mal einen 
Strich unter Zeit und Kosten, so haben wir dabei bislang immer Gewinn 
gemacht. Wenn es bei einem Projekt etwas länger gedauert hat, dann ging 
es bei einem anderen um so schneller! Wenn es mal ein Problem gab, 
konnten wwir helfen, meist sofort, weil wir nicht kugekauft, sondern 
selber verstanden hatten.

Gruß, Ulrich

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zurück zum Thema und eine Teillösung ( Also bitte weiter gute Tips!):

Viele Threads hier weisen in der Kombination OpenOCD-USB als Hardware 
und openocd-ftd2xx als Software in die falsche Richtung. Mit ein wenig 
Mut es einfach mal anders zu probieren,

Schritt 1:
Den FTDI Treiber von deren Homeapage laden und installieren. Der 
OpenOCD-USB meldet sich als Dual RS232 A und Dual RS232 B in der 
Systemsteuerung.
Der Treiber kennt, wie nicht anders zu erwarten, die VID 0403 und die 
PID 6010, logisch, ist ja der Treiber des Chip Herstellers. Eine andere 
VID/PID ist auch nicht zu erwarten, der OpenOCD-USB hat ja das EEPROM 
nicht bestückt.

Schritt 2:
Aus dem Interface Verzeichnis unter Programme/OpenOCD-r717 ein cfg 
kopieren, dass oocdlink als Link-Protokoll verwendet. Ich habe es 
einfach mal OpenOCD-USB.cfg genannt. Hier die VID und PID gegen 
0403/6010 austauschen und openocd-ftd2xx -f interface\OpenOCD-USB.cfg 
aufrufen.
Es geht natürlich schief, aber endet mit der Meldung der beiden Namen 
der Kanäle vom OpenOCD-USB Dongle:
Dual RS232 A
Dual RS232 B
Da man ja vorher nicht in die Systemsteuerung geschaut hat, Schritt 1 
ist ja nur so ausführlich, weil ich ewig gesucht habe, schnappe ich mir 
also cut'n'paste die erste Zeile: Dual RS232 A und ersetze den Amontek 
Text in meiner OpenOCD-USB.cfg durch eben diesen String.

Ruft man nun openocd erneut mit dieser cfg auf, so erhält man einen 
Treffer. Die Verbindung zwischen OpenOCD-USB Hardware und openocd-ftd2xx 
Software steht.

Schritt 3:
In den Scripten und cfg Dateien gibt es ein nicht wirklich klaren 
Zusammenhang, der sich uns aber nicht erschlossen hat. Ich kann nur 
vermuten, dass man sich die Dateien nach Adapter, Debugger und Ziel 
Plattform als openocd -f interface -f target -f platform -f script... 
zusammen stellen können soll. Daher lasse ich das mal abseits.
Wir haben dann in der sam7x256.cfg den Pfad auf die sam7x-reset.script 
geändert, der in der Installation auf ein ./prj/ verweist. Ich vermute 
an dieser Stelle, dass das eine Sache für Eclipse ist.

Jetzt meldet sich das openocd mit unserer cfg bereits und nimmt über 
Telnet Befehle entgegen, ohne eine Fehlermeldung: Cool!

Schritt 4:
Bevor ich mich ans Debuggen machte, wollte ich erest mal ein 
Demo-Programm flashen. Also habe ich mir aus der YAGARTO Anleitung oder 
dem Berlios Link eines dieser at91sam7x-test gezogen, dass die LEDs 
abwechselnd blinken lässt und mir zudem aus dem Nut/OS das http Demo 
compilieren lassen.
Da gibt es ein Flash Script im openocd und man muss nur den Dateinamen 
des .bin in einer der letzten Zeilen anpassen. Dachte ich...
Also das Script, dessen Namen ich nachreiche, wenn ich aus meinen 
Erfahrungen einen Wiki eintrag verfasse, zusammen mit der zuvor 
erstellten cfg aufrufen und es scheint ein Flashen statt zu finden.

LEIDER LEIDER....
funktioniert das nicht, wie man aus meinem Post weiter oben entgegen 
nehmen kann. Obwohl augenscheinlich alles Läuft und auch ein -d 1 
Debug-Meldungen auswirft für jeden geflashten Block, die nicht weiter 
problematisch aussehen, ist der Flash nachher unbrauchbar. Es startet 
nichts.
Wir brauchen Schritt 5...

Schritt 5:
Warum flasht der und flasht doch nicht... Es gibt Hinweise in diversen 
nie wirklich beendeten Threads in diveresen Foren, dass das Timing etwas 
damit zu tun hat... Schaut man sich im at9sam7x.cfg die Einstellungen 
an, die in die PLL-Register und FlashCFG Registere des AT91SAM7X 
geschrieben werden, so kann man diese nicht auf anhieb nachvollziehen. 
Da ist beim Flashen der USB Teil der PLL aktiviert und die Multiplier 
stehen auf Werte, die für ein 16MHz gelten könnten ( ich habs nicht 
nachgerechnet). Das von uns genutzte AT91SAM7X-EK hat abere ein 
18,432MHz Quarz, was nahelegt, dass wir uns unter die Overclocker 
begeben haben...
Ich habe mir die Default-Werte im AT91SAM7X Zweig des Nut/OS angesehen 
und dort andere Teiler und Multiplier vorgefunden. Also die PLL-Settings 
auf diese Einstellungen geändert. Damit rennt die PLL bei etwas um die 
94MHz. Nun kann man auch den Teiler eine Zeile tiefer von 0x0000000B auf 
0x00000007 also auf /2 ändern und man hat irgendwas um die 48Mhz 
Systemtakt.
Während ich die PLL Einstellungen aus dem Datenblatt detailliert 
nachvollzogen habe, da ich sie für die Programmiereung eh brauche,
habe ich den Wert für die FlashCFG aus einem MAC-OS Script hier aus dem 
Forum geklaut. Es war schon spät...

Nun habe ich das Script fürs Flashen erneut aufgerufen und ... Yeaha! Er 
flasht. Könnte was schneller gehen, aber da kann man sicher noch was 
machen. Wir haben jetzt auf auf zwei Rechnern die Scripte ausprobiert 
und konnten erfolgreich beliebige BIN Dateien in den ARM flashen.

OFFENE PUNKTE
Nun gibt es noch ein oder zwei Aufgaben:
Eclipse und das ZylinCDT Plugin sind installiert und das kleine 
Test-Programm aus YAGARTO oder Berlios kann auch compiliert und debugt 
werden. Leider nur ein paar mal, dann gibt es die Fehlermeldungen aus 
meinem vorhergehenden Posting.
Es bleibt also noch:
Debuggen aus Eclipse
Flashen aus Eclipse
Optimierung des Speeds

Vielen Dank an alle Poster rund ums Thema openocd und sam7 die mir mit 
ihren, leider meist unvollständigen Threads, doch den richtigen Weg 
gezeigt haben :)

Wastl, Lorenz und Michael, habt Ihr, oder jeder andere geneigte Leser, 
noch ein Paar Ideen das ganze zu optimiern und zu einem brauchbaren 
System zu bringen?

Wie gesagt, wenns fertig ist, würde ich gerne ein Wiki draus machen, 
damit alle was davon haben. Ich lasse meinen eigenen PC jetzt 
unverändert, damit ich das ganze zuletzt noch mal komplett 
nachvollziehen kann und dann auch ein paar aussagekräftige Screeshots 
zur verfügung habe.
Danach werde ich das ganze noch einmal mit dem usbprog durch spielen. Es 
liegen hier auch noch zwei Sattellitenreceiver mit geschossenem Flash, 
da ist also auch die Anpassung an weitere JTAG Targets noch als 
Beschreibung drinn.

Gruß, Ulrich

Autor: Bri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach dir nicht zu viel Mühe mit dem Wiki. Ich habe vor kurzem ein Olimex 
Board gekauft und wollte es "mal fix" mit OpenOCD programmieren. Das 
ging aber nicht so ohne weiteres. Die Kommandosyntax wurde 
zwischenzeitlich einfach mal geändert, die Doku nicht. Die aktuelle 
Version im Repository funktionierte nicht mit meinem Wiggler Adapter, 
eine ältere ging zum Glück. Ein Bekannter von mir hat einen USB Ammon 
JTAG Key (heißt der so?). Er hat ihn nur unter Windows mit OpenOCD zum 
Laufen bekommen. Sein Wiggler Adapter läuft nur unter Linux mit OpenOCD. 
In soweit kann ich "..." schon zustimmen. Naja, einem geschenkten Gaul 
schaut man nicht ins Maul. Ich wünsch dir noch viel Glück.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Bri!
Kann ich nachvollziehen, dass das frustrierend ist.

Aber da sind wir dann vermutlich auch mit unterschiedlichen 
Einstellungen am Werk. Wenn das nicht funktioniert, dann nehme ich es 
auseinander und bau es um und setze es wieder zusammen, bis es so 
funktionieret, wie ich es brauche. Natürlich gibt es auch da Grenzen. 
Windows-Programmierung ist garnicht mein Fall. Aber auch würde ich mich 
durchbeißen.
Daher habe ich auch den OpenOCD genommen anstelle des usbprog. Der 
FT2232 ist eine feste Konstante, so muss ich nur mit Treibern, Configs 
und INIs kämpfen. Beim OpenOCD wäre neben dem Windows Backend auch noch 
ein AVR Software Frontend dabei. Also eine Baustelle weniger.
Weiterer Vorteil der openocd Software ist, dass man sie in verschiedenen 
Versionen nebeneinander installieren kann. Es ist also ein leichtes, den 
funktionierenden Stand mit ein zu checken und zu archivieren.

Damit kann man den Stand auch nach längerer Zeit immer wieder 
herstellen.

Ist aber eine Grundregel: Alle zum Projekt gehörenden Dateien und Tools 
werden zusammen archiviert.

Der usbprog kommt drann, wenn ich etwas mehr Zeit habe. Momentan läuft 
das Projekt gegen meinen Urlaub und ich möchte wirklich, dass der Urlaub 
gewinnt :) und danach sieht es bislang auch aus.

Gruß, Ulrich

Autor: wowie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

hat sich da was ergeben in der letzten Zeit?


Gruß Wolfgang

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Lege gerade wieder los. Allerdings starte ich aktuell den Versuch unter 
Linux. Fest steht schon mal, dass die mit gelieferten Scripte für den 
at91sam7x von den Einstellungen für die PLL nicht korrekt sind, wenn man 
das SAM7X-EK verwendet. Dieses hat ein 18.432MHz Quarz.

Irgendwie lässt sich das X-EK aber nur einmal flashen. Dann mag der 
open-ocd nicht mehr. Auch funktioniert das Flashen nur alle paar mal, 
obwohl identische Status Meldungen zurück kommen. Und aus dem Reset 
erwacht das System nach dem Flashen auch nur bei 40% der Versuche. Bei 
allen anderen hängt er fest im Reset und Supervisor Mode.

Aber ich bin jetzt wieder drann.

Gruß, Ulrich

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich arbeite auch mit dem AT91SAM7x-EK

ich versuche - mit OpenOCD r1570 unter Ubuntu Linux 9.04 - verzweifelt 
etwas per Boundary Scan aus dem Controller zu holen.

Ideal wäre dafür zum Beispiel die ID aus dem IDCODE Register. Dieses 
lässt sich per IR-Adresse 0xE ansprechen (sagt das ARM-Manual)

ein
-> irscan sam7x256.cpu 0xE
bringt keine fehler. (soweit sogut)

das 'ausschieben' von 32 bit aus dem Data Register sollte nun die 32-Bit 
ID bringen...

-> drscan sam7x256.cpu 32 0x0
=> 10000000

es kommt aber nur 10000000

Habt ihr, oder vielleicht speziell Du, Ulrich, eine Ahnung was ich hier 
falsch mache?

Viele Grüße
 - Thorsten

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich habe die Konfiguration mit dem r1000 unter windows und linux am 
laufen. Aber ich verwende bislang nur das flashen, da die Applikationen 
für die Firma und zu Hause das EIR doch recht übersichtlich sind. Da war 
bislang das JTAG Debugging nicht erforderlich.
Werde das nach dem laaangen Wochenende vielleicht mal angehen, da ich 
dann einige neue Sachen mit den SAM7 angehen muss.

Ich melde mich dann dazu.

Gruß, Ulrich

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab mich vor einigen tagen an meinen openOCD usb-adapter von 
in-circuit (icprog openocd , auch von embedded-projects erhältlich) 
rangesetzt. da von dieser firma kein support zu bekommen war, musste ich 
mich selber durchbeißen. dieser thread hat schon gut geholfen!

aber da ich meinen adapter nicht unter windows zu laufen bekommen hab, 
probierte ichs unter linux.
dieser adapter benutzt den FT2232 usb-uart/fifo umsetzer, welcher mit 
openocd mit
- opensource bibliothek libftdi
- closed source bibliothek ftd2xx (ftdichip.com)
betrieben werden kann.
die closed variante ging bei mir nicht (weder mit offiziellem 0.5.0 code 
release, noch aktuellem git).

ich habs mit der opensource bibliothek zum laufen gebracht und eine 
kleine installationsanleitung für linux-neulinge geschrieben. (openocd 
mithilfe von aktueller git version auf steinaltem centos linux erstellen 
(yum paketmanager))
siehe hier:
http://forum.sparkfun.com/viewtopic.php?f=18&t=32871
(HOWTO: Building OpenOCD for FT2232 from scratch with libftdi)

vermutlich wirds in zukunft auch solche wie mich geben, die sich über 
jedes howto gefreut hätten ;).

gruß
flo

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.