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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
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
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.
Gast
#993540
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
Augenscheinlich funktioniert da auch was, ich erhalte jede Menge:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Aber das ganze endet mit:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
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 | |
2 | |
3 | |
4 | |
Hier der Log aus der openocd console:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Irgendwie kommt der Debugger nicht mehr zurück... Irgendeine Idee? Danke vorab, Ulrich
Gast
#993803
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
Gast
#994653
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
Gast
#1126274
Hallo hat sich da was ergeben in der letzten Zeit? Gruß Wolfgang
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
Gast
#1269936
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
Gast
#2730678
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
Bitte melde dich an, um einen Beitrag zu schreiben.