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_mit_OpenOCD_programmieren
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
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
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:
Error: ft2232.c:1436 ft2232_init_ftd2xx(): 0: Dual RS232 A
11
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
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!
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:
1
#daemon configuration
2
#interface
3
interface ft2232
4
ft2232_device_desc "Dual RS232 A"
5
ft2232_layout oocdlink
6
ft2232_vid_pid 0x0403 0x6010
7
jtag_speed 100
8
jtag_nsrst_delay 200
9
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:
1
#reset_config trst_and_srst
2
#use combined on interfaces or targets that can't set TRST/SRST separately
3
reset_config srst_only srst_pulls_trst
4
5
#jtag scan chain
6
# format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
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
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:
1
Breakpoint 1, main () at src/main.c:69
2
69 DWORD a = 1;
3
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0
4
kill
Hier der Log aus der openocd console:
1
User: target.c:1838 handle_soft_reset_halt_command(): requesting target halt and executing a soft reset
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.
;-)
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
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
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.
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
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
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
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
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
Thread beobachten
Seitenaufteilung abschalten