Wenn ich das Board des Xilinx/Digilent Spartan-3E-Starterkit per
USB-Kabel von meinem Linux-Rechner (2.6.17.1) mit iMPACT (ISE 8.1.03i
oder 8.2.01i) programmieren möchte, poppt beim Verbindungsaufbau (z.B.
über dem Menüpunkt "Cable Setup") folgende Meldung auf:
| WARNING:iMPACT:2356 - Platform Cable USB firmware must be updated.
This
| operation may take up to 10 minutes on a USB 2.0 port or up to 30
minutes on a
| USB 1.1 port. Please do not stop the process or disconnect the cable
prior to
| completion. The cable STATUS LED will be RED for the duration of the
update
| process.
| [ OK ]
Wenn ich OK klicke, fängt tatsächlich ein Update-Prozess, wie in der
Meldung angekündigt, an. Beim nächsten Versuch erscheint die Meldung
wieder.
Wer hat
- das gleiche Problem,
- das Problem nicht, obwohl er ein Xilinx-Board (vielleicht auch ein
anderes als
das Spartan-3E) per USB am Linux-Rechner hängen hat oder
- eine Lösung des Problems?
Ein bereits seit Wochen laufender Dialog mit dem Xilinx-Support hat
bisher noch nicht den entscheidenden Durchbruch gebracht. Deswegen
hätte es mich interessiert, ob ich der einzige auf der Welt bin, der
dieses Problem hat oder vielleicht sogar der einzige, der das Board in
dieser Umgebung nutzt.
Hier noch ein paar weitere Infos, die interessant sein könnten:
Unter Windows tritt das Problem nicht auf. Deswegen schließe ich einen
Hardwaredefekt aus.
Wenn ich bei eingeschaltetem Board das USB-Kabel aus- und wieder
einstecke, funktioniert's auch unter Linux. Mit diesem Workaround kann
ich im Moment ganz gut leben, aber nervig ist's trotzdem. Wird das
Board aus- und wieder eingeschaltet, ist das Problem auf's Neue da.
Das Firmware-Update bezieht sich auf das XC2C256-CPLD auf dem Board,
das wohl zusammen mit dem CY7C68013A-Mikrocontroller für die
USB-JTAG-Umsetzung zuständig ist.
iMPACT gibt im Fehlerfall folgendes Log aus:
------------------------------------------------------------------------
---
Welcome to iMPACT
// *** BATCH CMD : setMode -bs
// *** BATCH CMD : setMode -bs
// *** BATCH CMD : setCable -port ttyS1 -baud -1
Reusing A10173F5 key.
Reusing 250173F5 key.
Connecting to cable (Usb Port - USB22).
Checking cable driver.
File version of /home/xilinx/bin/lin/xusbdfwu.hex = 1021(dec), 03FD.
File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1021(dec),
03FD.
Cable PID = 0008.
Max current requested during enumeration is 150 mA.
Cable Type = 3, Revision = 0.
Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 1021.
CPLD file version = 0012h.
CPLD version = 0000h.
WARNING:iMPACT:2356 - Platform Cable USB firmware must be updated. This
operation may take up to 10 minutes on a USB 2.0 port
or up to 30 minutes on a USB 1.1 port. Please do not stop the process
or disconnect the cable prior to completion. The cable
STATUS LED will be RED for the duration of the update process.
------------------------------------------------------------------------
---
Nach Anwendung des Workarounds (Aus-/Einstecken des USB-Kabels) sieht
das Log folgendermaßen aus:
------------------------------------------------------------------------
---
--Welcome to iMPACT
// *** BATCH CMD : setMode -bs
// *** BATCH CMD : setMode -bs
// *** BATCH CMD : setCable -port ttyS1 -baud -1
Reusing A10173F5 key.
Reusing 250173F5 key.
Connecting to cable (Usb Port - USB22).
Checking cable driver.
File version of /home/xilinx/bin/lin/xusbdfwu.hex = 1021(dec), 03FD.
File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1021(dec),
03FD.
Cable PID = 0008.
Max current requested during enumeration is 280 mA.
Cable Type = 3, Revision = 0.
Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 1021.
CPLD file version = 0012h.
CPLD version = 0012h.
------------------------------------------------------------------------
-
Im Fehlerfall gelingt es der Software offensichtlich nicht, die
CPLD-Firmwareversion zu erkennen und wird deswegen als 0000h
angenommen. Da die aktuelle, im ISE-Paket enthaltene Version aber 0012h
ist, wird die Notwendigkeit zum Update gesehen. Im zweiten Fall wird die
Version sofort richtig erkannt (0012h), so dass problemlos
weitergearbeitet werden kann.
Es gibt ein paar wenige Howtos zum Thema ISE+Linux im Netz, die bei
diesem Problem aber auch nicht weiterhelfen.
Meine letzte Hoffnung war ISE 8.2i (+SP1). Diese hat sich gerade eben
zerschlagen :-(
Hi,
Bei uns an der Uni müssen wir den "Rausziehen - Reinstecken"
Workaround auch machen (Xilinx XUP Board's)! Mit diversen Distro's
immer das gleiche Problem.
Ein WiMi hatte mal die von Xilinx vorgeschlagene Distro (RedHat, oder
so?) installiert. Da geht es ohne rausziehen und reinstecken direkt.
Haben dann den RedHat Kernel genommen und damit ein Debian gebootet das
hat aber auch nicht geklappt. Liegt also wohl nicht am Kernel sondern an
der "Userspace" Software.
BTW: Weißt Du wann es 64-Bit Treiber für das Impact gibt (xpcdrvr)?
Gruß,
Gregor
@Gregor
Viele Dank für die Info. Jetzt weiß ich wenigstens, dass es nicht an
meiner Selbstbaufrickeldistro liegt.
Irgendwie habe ich das Gefühl, dass es sich dabei um ein Timimg-Problem
bei der ersten Einrichtung des USB-Geräts handelt. Diese geschieht in
mehreren Stufen:
Nach dem Einschalten des Boards hat der Cypress FX2-Mikrocontroller auf
dem Board, der das USB-Interface realisiert, noch keine
anwendungsspezifische Software an Bord. Diese wird vom PC nach Erkennen
des USB-Geräts upgeloadet. Danach wird der FX2 resettet und meldet sich
mit anderen IDs (diesmal als Xilinx-Produkt) erneut am USB an. Dabei
wird es aber immer noch mit 12 Mbit/s eingerichtet, obwohl 480 Mbit/s
auf beiden Seiten möglich wären. Nach dem Aus- und Einstecken werden
dann auch die 480 Mbit/s angezeigt. Die FX2-Software wird dabei nicht
ein zweites Mal upgeloadet und der FX2 nicht nochmals resettet.
Deswegen vermute ich, dass beim ersten Versuch (direkt nach dem Upload)
irgendwas auf dem FX2 noch nicht ganz initialisiert ist, nach dem
Aus-/Einstecken aber sehr wohl, da die Software dabei nicht neu
gestartet wird.
Vielleicht braucht man tatsächlich eine Distro, die sich mit der
Einrichtung der USB-Geräte etwas mehr Zeit lässt.
Es gibt übrigens eine relativ neue Version der FX2-Software unter
ftp://ftp.xilinx.com/pub/utilities/fpga/xusbdfwu.zip
Diese ist sogar zwei Versionsnummern neuer als die mit 8.2i SP1
mitgelieferte Version und behebt immerhin das 12/480-Mbit/s-Problem.
Aber Aus- und Einstecken muss man immer noch :-(
nochmal @Gregor
Entschuldigung, ich hatte ganz verpennt, Deine Frage zu beantworten,
auch wenn dei Antwort Dir wahrscheinlich nicht arg weiterhilft:
Nein, ich weiß leider nicht, wann die 64-Bit-Treiber für Impact kommen.
Aber frag doch mal beim Xilinx-Support nach. Nach dem die Hürden der
Registriererei überwunden sind, sind die Leute dort eigentlich sehr
hilfbereit.
Kann mal jemand den Link posten, wie beschrieben ist, wie ich die
Treiber fuer das Webpack unter 2.16.7 und neuer erstellen kann? Bei mir
kommt das Problem, daß exportierte Funktionen nur mit GPL-Code laufen,
2.6.16 ist der Kernel der bei mir deswegen läuft (ich weiss, man muss
nicht immer das neueste haben ;) ).
thnx
Hallo zusammen,
ich habe auch mind. eine Woche damit verbracht Impact unter Linux (32
Bit) zum laufen zu bekommen -- alles nur begrenzt erfolgreich.
Ich Benutze jetzt http://inisyn.org/src/xup/ -- das funktioniert ganz
hervorragend...
Danke, werd mir mal ansehen. Ich hab nur 1Tag gebraucht :))), und bin
halt auf 2.6.16 umgestiegen, weils die einzigste moeglichkeit (ausser
nochaelter) war :(((((.
Ist das WebPack bei euch auch so lahm? (ok unter win ist es das auch ;)
), aber bis impact startet oder gar pace, das ist nicht akzeptabel.
0%systemauslastung, und trotzdem bis zu 1-2 min (grob geschaetzt).
Portmap ist gestartet, aber kein geschwindigkeiitsvorteil. oder muss
noch was configuriert werde? ich nutze gentoo, und habs einfach nur
gestartet, ohne config etc
Hi!
Ich versuche gerade das Webpack 8.2i zusammen mit dem Spartan-3E Kit
unter Ubuntu (Kernel 2.6.15) zum Laufen zu bringen.
Welche Treiber habt ihr denn installiert? Ich habe den Windriver 802,
aber beim einstecken wird das Board scheinbar nicht erkannt. Brauche ich
irgendwelche weiteren Treiber?
Sebastian
Hi!
Ich habe ein ähnliches Problem mit einem Digilent XUP-V2Pro (VirtexII)
Board.
Habe Ubuntu 8.04 und die Xilinx ISE 9.1i installiert.
Habe die Kabeltreiber nach dieser Anleitung installiert:
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/archive/2007/03/msg00101.html
Hat soweit auch alles funktioniert. Es wurde die Cable-Firmware
geupdatet und anschliessend im Impact erfolgreich der Boundary-Scan
durchgeführt. Sprich der FPGA auf dem Board wurde erkannt.
Das hat aber leider nur einmal geklappt. Jedesmal, wenn ich jetzt Impact
starte, will er das Firmware-Update erneut durchführen (dauert dann
jedesmal ca. 40min).
Wenn ich in der Konsole, wie in der Anleitung oben beschrieben, "lsusb |
grep Xilinx" eingebe, erhalte ich die neue Firmware Version:
Bus 001 Device 008: ID 03fd:0008 Xilinx, Inc.
(Vor dem ersten Update war es 03fd:0009).
Also scheint das Update ja geklappt zu haben, aber Impact rafft das
irgendwie nicht.
Was kann ich tun???
Und wie genau soll der rausziehen/reinstecken-Trick funktionieren?
Danke euch!!!
Also irgendwas scheint da nicht zu stimmen unter Linux. Die Firmware
befindet sich doch gar nicht auf dem Programmer selbst, sondern wird
beim Antecken erst mal über die USB-Load Funktion des Cypress FX2
herunter geladen. Unter Windows passiert das wie oben geschrieben in
mehreren Stufen, insgesamt werden während des kompletten Prozesses 3
verschiedene USB Geräte erkannt. Zumindest beim roten USB II Cable.
Hallo Christian,
erstmal vielen Dank für Deine Antwort.
Aber jetzt mal langsam... Bin nämlich noch ein ziemlicher Newbie :)
Was meinst Du mit dem "Programmer"? Was ist der FX2? Ich nehme mal an,
dass ist der Chip auf dem Virtex-Board, der neben der USB-Buchse sitzt?!
Da steht "CY7C68013A" drauf. Dieser Chip enthält also die Firmware?!
Ich habe hier kein rotes USBII-Kabel, sondern ein stinknormales USB (A
auf B)-Kabel. Mitgeliefert wurde ein aufrollbares Kabel:
http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable
(das 9. von oben).
Da ich diesem Kabel nicht wirklich vertraut habe, habe ich es nach
einigen Versuchen gegen ein standard-USB-Kabel ausgetauscht und noch
einmal das Firmware-Update durchgeführt.
Danach wurde der Virtex auch wieder von Impact erkannt. Sogar nach
Rechner-Neustart, Board ein-/ausschalten oder USB-Stecker ziehen.
Das musste es gewesen sein, dachte ich...
Aber nun ist das Problem wieder das selbe. Habe gerade nach dem
Wochenende meinen Rechner hochgefahren (das Board schon vorher
eingeschaltet) und Impact gestartet.
Impact versucht den Boundary-Scan durchzuführen, benötigt aber (statt
<1s wie sonst) fast eine Minute um bis 10% hochzulaufen und sagt dann
sowas wie: "Es werden scheinbar falsche Komponenten erkannt, soll der
Scan trotzdem fortgeführt werden?".
Nach raus-/reinstecken des USB-Kabels kommt dann wieder die "Wir
brauchen ein Update..."-Meldung.
Also nochmal "lsusb..." in die Konsole getippt und diesmal spuckt er
wieder 03fd:0009 aus. Also das Board nochmal ein-/ausgeschaltet und es
wird wieder 03fd:0008 erkannt. Ich halts nicht mehr aus...
Ich werde jetzt mal Windows anschmeissen heul.
Naja, ich kenn das Board nicht wirklich, wir haben hier natürlich die
richtigen Programmer von Xilinx. Aber ich vermute, dass der USB Chip auf
der Platine genau die Funktion des Programmers übernimmt, denn im roten
Programmer steckt auch nur ein FX2. Also der Cypress 68013. Und genau
der enthält eben nicht die Firmware, sondern die liegt als File auf dem
Rechner und wird beim Enumerieren des USB Gerätes runtergeladen. Das USB
Ding meldet sich erst mal als Standard-Device an, dann wird die Firmware
geladen, dann macht es einen Reset und startet mit der neuen Firmware im
RAM eine neue Enumeration. Ich denke eher, der Fehler liegt irgendwo in
der USB Firmware Load Geschichte bei Linux. Unter Windows ist das auch
schon nen bissl aufwendig, unter Linux ist ja sowas immer aufwendig hoch
14....du solltest mal das Log anschauen, was passiert, wenn du das Board
ansteckst (vorher Power am Board aus und wieder an).
Leider ist die Seite im Schaltplan, die das USB Interface beschreibt
ausgespart....
Also Du hast recht. In der Anleitung vom Board steht, dass der
eingebaute Chip sich genau wie das Xilinx-Kabel verhält.
Dort steht auch, dass bei jeder Verbindung der (Zitat) "application
code" runtergeladen wird. Aber was bitte passiert dann 40min lang beim
update durch Impact??? Ergibt für mich alles nicht viel Sinn...
Jedenfalls hab ich es jetzt mit Windows probiert. Zuerst hat Impact auch
hier ein Update durchgeführt und der BoundaryScan hat geklappt.
Eigentlich ist es aber am Ende das gleiche Problem wie unter Linux.
Manchmal gehts, manchmal will er das Update erneut machen.
Komischerweise hat es dann auch funktioniert, als ich das Update
abgebrochen habe und einfach nochmal "Initialize Chain" angeklickt habe.
Merkwürdigerweise sagt Windows auch immer "Dieses USB-Gerät kann eine
höhere Leistung erzielen...", sprich er meint, ich hätte ne
USB1.1-Buchse erwischt. Der Rechner hat aber ausschliesslich USB2.0 und
es ist egal, welchen Anschluss ich nehme. Mein Laptop (ebenfalls WinXP)
gibt übrigens die gleiche Meldung aus.
Zusammenfassend kann ich sagen, dass es unter Windows zwar häufiger,
aber auch nicht immer klappt...
Sehr komisch, bei mir unter XP SP2 geht das rote Kabel einwandfrei, ist
ja offensichtlich dann die gleiche Firmware, denn USBView sagt:
1
Device Descriptor:
2
bcdUSB: 0x0200
3
bDeviceClass: 0x00
4
bDeviceSubClass: 0x00
5
bDeviceProtocol: 0x00
6
bMaxPacketSize0: 0x40 (64)
7
idVendor: 0x03FD
8
idProduct: 0x0008
9
bcdDevice: 0x0000
10
iManufacturer: 0x01
11
iProduct: 0x02
12
iSerialNumber: 0x00
13
bNumConfigurations: 0x01
14
15
ConnectionStatus: DeviceConnected
16
Current Config Value: 0x02
17
Device Bus Speed: Full
18
Device Address: 0x02
19
Open Pipes: 2
20
21
Endpoint Descriptor:
22
bEndpointAddress: 0x02
23
Transfer Type: Bulk
24
wMaxPacketSize: 0x0200 (512)
25
bInterval: 0x00
26
27
Endpoint Descriptor:
28
bEndpointAddress: 0x86
29
Transfer Type: Bulk
30
wMaxPacketSize: 0x0200 (512)
31
bInterval: 0x00
Beim Anstecken kommt auch zwischendurch mal kurz die Meldung, dass es an
einem anderen Anschluss höhere Leistung erzielen könnte, aber der
Rechner hat nur HighSpeed Anschlüsse. Ist also Quatsch. Außerdem hätte
man dann keine 512 Byte Paketgröße.
Ich musste unter Win allerdings erst noch so nen komischen extra Treiber
installieren. Nennt sich ug344_windows.zip bei Xilinx. Erst dann ging´s
richtig.
Hi Christian,
also USBview zeigt bei mir das gleiche an.
Ich bin jetzt mit dem Xilinx-Support in Kontakt.
Werde mich melden, wenn das Problem gelöst wurde...
Erstmal noch Danke für Deine Hilfe!
Mahlzeit!
Ich habe jetzt mit dem Xilinx-Support ein work-around erarbeitet. Etwas
kompliziert, aber funzt bei mir IMMER.
Das Problem ist wohl, dass sich das Board nach dem Einschalten irgendwie
verhaspelt und daher nicht immer erkannt wird. Helfen tut da das Drücken
des RESET/RELOAD-Buttons auf dem Board. Damit das initialisieren der
Chain immer funzt, gehe ich wie folgt vor:
Die drei Devices (PROM, ACE, Virtex) der Chain manuell in Impact
hinzufügen. Dann auf Output -> Disconnect all Cables.
RESET am Board drücken.
Output -> Cable Setup. Auf Xilinx USB stellen und den Rest so lassen.
Danach lässt sich der FPGA programmieren :)
Wem diese "Kurzanleitung" nicht reicht, der soll sich melden, dann
schreib ich es nochmal Step-by-step genau auf.
Danke nochmal für eure Hilfe!
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten