XC3Sprog unter Windows 10 keine JTAG Kette gefunden

Gast #5135461
Lesenswert?

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.
Gast #5135465
Lesenswert?

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.
Gast #5135502
Lesenswert?

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.
Gast #5135541
Lesenswert?

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.
Gast #5135568
Lesenswert?

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?
Gast #5135680
Lesenswert?

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.
(Firma: TU Darmstadt) #5136603
Lesenswert?

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?
Gast #5136699
Lesenswert?

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.
Gast #5136724
Lesenswert?

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
(Firma: TU Darmstadt) #5136757
Lesenswert?

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;

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren