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).
Ist der "portmap" gestartet? Falls nicht dauert das starten der Tools bei mir auch ewig. Ansonsten ist alles fix oben.
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
@Sebastian: Ich brauchte bei 2.6.17 den WinDriver 8.11, hab allerdings 'nur' das ParallelCable. Rick
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.