Hallo Leute, ich habe immer XC3SPROG benutzt um die Firmware in den Xilinx Prog hochzuladen. Dies hat auch immer einwandfrei funktioniert. Jedoch benutze ich seid einige Zeit Windows 10. Ich habe den Ordner mit den Datein auf den neuen PC kopiert und dort meine Batch Datei ausgeführt. Leider wird die JTAG Kette nicht mehr gefunden. Jedoch bin ich mir sicher das es auf Windows 10 schon mal funktioniert hat. Hat einer auch solche Erfahrungen gemacht. Ich bin der Meinung das es mit dem letzten Windows 10 Update zusammen hängt, da es davor auch auf einem Windows 10 PC funktioniert hat. Im Gerätemanager wird auch unter USB Geräte der FTDI Chip FT4232H angezeigt.
Moin, Mach doch mal nen Screenshot von deinem Gerätemanager. Verwendest du den FTDI oder libusb-Treiber? Welche Version? Ich hatte schon ähnliche Spässe mit aktuellem Win10, da muss irgendwas bei der Enumeration falsch gelaufen sein. Ich habe dann alle ausser das erste (JTAG)-Device deaktiviert, dann ging's.
Angehängte Dateien:
-
FTDI_Treiber_Version.png
15 KB -
Geraete_Manager.png
24 KB -
JTAG_Kette_not_found.png
11 KB
Ich verwende die Treiber von FTDI Chip.
Michael schrieb: > Wie könnte ich den die JTAG Nummerierung zurücksetzen? Ich weiss die Registry-Hacks nimmer auswendig, aber im Prinzip ging das da früher. Neuere Win-Versionen erlauben aber teils nicht mal dem Admin noch den Zugriff auf manche Keys. Probier doch mal, "Serial Converter B" zu deaktivieren. Ev. auch die USB-Composite unten, wenn die zum 4232 gehören. Sehr nützlich ist auch USBdeview (http://www.nirsoft.net/utils/usb_devices_view.html) zum Treiber deaktivieren/testen.
Tausend Dank es hat sehr geholfen. :-) Ich habe im Gerätemanager den USB Serial Converter B deaktiviert. Dadurch ist nur noch der USB Serial Converter A vorhanden. Und schon wurde die JTAG Kette erkannt. Jedoch musste ich nie den Converter B deaktivieren.
Bei einigen Projekten benötige ich natürlich den Port B, deshalb ist das ständige aktivieren und deaktieren der Ports nicht gerade die perfekte Lösung. Kann ich die Deaktivierung um Gerätemanager umgehen?
Ich benutze anstelle des FT4232H den FT2232H von FTDI. Dieser besitzt Port A und Port B. Auf beiden Ports ist je ein JTAG Interface vorhanden (Pin 0 bis Pin3). Jedoch ist nur das JTAg Interface von Port A bei mir an den FPGA angeschlossen. Ich habe im Gerätemanager wieder den Port B aktiviert. Dadurch funktioniert der Upload nicht mehr. Mir ist aufgefallen das ich in der Cableist nicht definiert habe welchen Port er verwenden soll. Und genau hier kann ich angreifen. #Alias Type Frequency OptString ftdi ftdi 6000000 0x0403:0x6010::1 --> funktioniert nicht ftdi ftdi 6000000 0x0403:0x6010::2 --> funktioniert einwandfrei Demnach kann ich die Batch-Datei ändern und prüfen ob die JTAG Kette erkannt wird. Wenn die JTAG Kette nicht erkannt wird kann ich Port B probieren. Wenn der auch nicht erkannt wird ist das Kabel auch nicht angesteckt.
Bei Verwendung der FTD2XX Bibliothek ist die Erkennung des FTDI Devices unterschiedlich bei Linux und Windows. Da ich unter Linux arbeite, ist xc3sprog so programmiert, dass es unter Linux funktioniert. Sobald es mehr als ein FTDI Device gibt, ist es bei Windows wohl Glueckssache welches Device gewaehlt wird. Damit es auch unter Windows funktioniert, sollten die vorhandenen FTDI Devices mit FT_CreateDeviceInfoList() aufgezaehlt werden, die Informatinen ueber FT_GetDeviceInfoList() bereitgestellt werden und dann mit FT_GetDeviceInfoDetail() das richtige Device ausgewaehlt werden um dann schliesslich mit FT_Open() das richtige Device zu oeffnen. Irgendwelche Freiwilligen fuer einen Patch?
Moin, die Enumeration ist eigentlich innerhalb der `FT_GetDeviceInfoList` zumindest unter WinXP und Win7 konsistent, das funktioniert bei mir schon jahrelang mit dem ICEbear JTAG. Nur bei neueren Win10 scheint irgend ein Wurm drin zu sein. Bin mir noch nicht sicher, ob es der FTDI-Treiber ist oder mal wieder eine Eigenheit schlecht getesteter Microsoft-Releases. Da der Win10-Kram in Bezug auf Treiber eine Menge Industriekunden nur Zeit kostet, würde ich zu einem Downgrade auf Win7 raten.
Hi Uwe (Namensvetter ;-), ich habe das Problem von Michael jetzt "umgangen" in dem ich per batch die Konsolenausgabe parse und bei einem Fehler auf den anderen Port umschalte (das Funktioinert wunderbar) jetzt taucht ein zweites Problem auf... ich wollte in der batch nach dem programmieren den Errorlevel auswerten um einen Fehler zu erkennen und dem Anwender anzeigen zu können. leider bekomme ich bei einem Fehler wärend des 'Verifys' den Errorlevel 0 zurück (also der gleiche Level wie ohne Fehler) beim 'Erase' und beim 'Programming' wird bei einem Fehler ein Errorlevel != 0 geliefert (so wie es sein sollte) hast du eine Idee wie ich sonst noch einen Fehler beim programmieren dedektieren könnte Gruß Uwe
Was fuer ein Device wird programmiert? XC2S, XC3C, XCF ...
XCF gibt immer nur 0 zurueck! Probier mal, ob der Patch hilft
diff --git a/xc3sprog.cpp b/xc3sprog.cpp
index 0bbfee9..5356334 100644
--- a/xc3sprog.cpp
+++ b/xc3sprog.cpp
@@ -1237,8 +1237,12 @@ int programXCF(Jtag &jtag, DeviceDB &db, int
argc, char **args,
return res;
}
}
- alg->verify(cur_bitfile);
+ res = alg->verify(cur_bitfile);
alg->disable();
+ if (res)
+ {
+ return res;
+ }
}
prom_pos += current_promlen;
Wir verwenden einen XCF16P. Leider habe Linuxsysteme und können daher den Code nicht selber compilieren. Wäre es möglich das Du uns eine compilierte Testversion zur Verfügung stellst?
Mit SVN Head sollte das Kompilieren unter Linux recht einfach gehen. > cd xc3sprog > mkdir build > cd build > cmake .. > make Ebenso das Crosskompilieren fuer Win32|64.
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.