XC3sprog mit FT2232H

Ich verwende ein Win7 64Bit Betriebssystem und die r401 Version von 
XC3sprog.

Wenn ich die Datei devlist.txt öffne dann steht dort kein Virtex 5 drin, 
obwohl auf der Internetseite steht das auch Virtex 5 FPGAs unterstützt 
werden. Zudem ist die Version ja schon von 2009 gibt es denn nicht 
aktuelles?

Ich habe aus diesem Link eine neuere Version gefunden:

Beitrag "xc3sprog: falscher IDCODE"

Dabei handelt es sich um die Revision $625

Damit erkennt er meine JTAG Daisy Chain und findet folgende Xilinx ICs:

Position 0: XCF32P
Position 1: XC5VLX30T

Und dies auch ohne die USBLIB sondern nur mit der D2XX.dll

NUR LEIDER FINDE ICH AUF DER SOURCEFORGE KEINE AKTUELLE VERSION NUR DIE 
VON 2009

Ich will aber nicht die libusb verwenden sondern die D2XX. Ich habe 
bereits den Treiber von FTDI installiert.

Es funktioniert einfach nur nicht mit der XC3SPROG Revision 401. Denn 
diese ist von 2009 und kann den FTDI Chip nocht nicht kennen. Die 
aktuelle Version 659 gibt es hier:

http://xc3sprog.svn.sourceforge.net/viewvc/xc3sprog/trunk/

Dann kann ich auch den FTDI FT2232H mit dem D2XX verweden. Ich habe 
momentan nur Probleme mit dem SVN :-)

Ich hatte aus dem nachfolgendem Link die XC3sprog Revision $625 
heruntergeladen. Diese erkennt auch meine beiden ICs in der JTAG Daisy 
Chain

Beitrag "xc3sprog: falscher IDCODE"

Wenn ich jedoch aus dem Soureforge Trunk die aktuelle Revision $659 
herunterlade, dann kann ich nicht das FTDI Device öffnen. Zudem wird die 
Revision $655 angezeigt.


Was mich ja wundert ist das die Revision $625 nur 0,3MByte groß ist 
während die Revision $659 gleich 5MByte groß ist, diese aber denn doch 
nicht funktioniert.

Ich habe eine (ungetestetes) Crosscompilat von Rev 709 nach Sourceforge 
hochgeladen. Am besten kompiliert man aber selbst aus den SVN Quellen. 
FTD2XX ist gegen der i-386 DLL aus  CDM 2.08.24 WHQL Certified.zip 
gelinky.

OK dann werde ich mal die neue 2.08.24 WHQL runterladen.

Ich komme leider nicht mit dem SVN auf die Seite. Benötigt man einen 
Sourceforge Account zum runterladen?

Kann ich mit folgenden Befehl mein msc File in den Xilinx Prom 
schreiben?

xc3sprog -c ftdi -L test.mcs

Ignoring unknown field '0'
Ignoring unknown field 'F'

zurück

Ich werde mal den neuen Treiber runterladen

So ich habe jetzt die FTDI Treiber Version 2.08.24 installiert.

Mit der Rev 709 kann ich auch wieder die JTAG Daisy Chain erkennen. 
Jedoch noch nicht das File in den Xilinx XCF32P schreiben

Ich habe mal den Parameter -e ausprobiert. Damit wird der XCF32P 
gelöscht. Er macht etwas das dauert so ca 20 Sekunden. Jedoch erscheint 
keine Info auf dem Display das gerade der XCF32P gelöscht wird und das 
dieser Prozess noch andauert. Wenn er fertig ist erhalte ich auch keien 
Rückmeldung ob dies erfolgreich war. Dies könnte man noch verbessern.

Zudem gibt es kein Log-File

xc3sprog -c ftdi -v test.mcs:w::MCS
muesste gehen. Die Kabeldefinition "ftdi" schaltet aber keine 
eventuellen Treiber zwischen dem FTDI JTAG Ausgaengen und dem JTAG Bus 
ein. Die meisten Kabel haben einen geschalteten Treiber und brauchen 
daher eine eigenen Definition in cablelist.txt. Viele Kabel sind aber 
schon definiert.

Ausserdem oeffnet obige Kabeldefinition alles was VID 0x403 und PID 
0x6010 hat. Das kann auch ein USB-Seriell Wandler sein, wenn er zuerst 
gelistet wird. Andere Kabel haben meist andere PID oder zumindestens 
andere Strings zur Unterscheidung.

Hallo UWE

ich kann doch den -s Parameter für die Serien Nummer benutzen oder den 
String Parameter, so kann ich sicherstellen das ich immer den richtigen 
FTDI Chip verweden.

Wenn ich Deinen Befehl benutze dann wird der Flash zuerste gelöscht. Es 
wird dann auch angezeigt das er gerade arbeitet. Wenn der Flash gelöscht 
wurde wird dies auch angezeigt. Auch die Zeit wie lange er für das 
Löschen gebraucht hat wird angezeigt.

Danach schaltet er in den Programming Mode und scheint den Flash zu 
beschreiben dies dauert jedoch recht lange, da die Frequenz auf 1,5MHz 
eingestellt ist. Bei einem 32MBit Flash dauert dies halt.

ES GIBT JEDOCH NOCH EIN PROBLEM:

Es wird angezeigt das die Checksumme in dem mcs File fehlerhaft ist

"incorrect record checksum found in mcs file"

Warum wird denn da für Progrmming frames und Verifying Frames ein 
unterschiedlicher Speicherbereich angezeigt?

Und warum werden keine Probleme mit der Checksumme angezeigt?

Auf jedenfall schon mal viele Dank für Deine Hilfe UWE

Es wird außerdem die Revision $691 angezeigt obwohl dies doch die 
Revision $709 sein soll.

Ich habe -J 10000000 die JTAG Frequenz auf 10MHz eingestellt. Jedoch 
wird immer noch eine JTAG Frequenz von 1,5MHz angezeigt.

Dadurch dauert das Flashen über 6 Minuten bei einem 32Mbit XCF32P

Sebastian schrieb:
> Revision $691

Das ist die SVN Revision des xcs3prog.cpp files. Wenn jemand einen 
besseren Vorschlag hat, bitte...

Benötigt man nur das mcs-file oder wird auch das cfi-file benötigt. 
Impact schreibt ja zum Beispiel die Checksumme in das cfi-file.

Ich habe bis jetzt nur das mcs-file in den Ordner von xc3sprog kopiert

Kannst Du die JTAG Geschwindkeit vom FTDI Chip noch beschleunigen. Diese 
ist nur auf 1,5Mbit eingestellt. Dies geht locker mit 10 oder 15Mbit. 
Nur leider bringt es nichts wenn ich den Wert verändert. Dies hat leider 
keinen Einfluss.

Sebastian schrieb:
> Ich habe -J 10000000 die JTAG Frequenz auf 10MHz eingestellt. Jedoch
> wird immer noch eine JTAG Frequenz von 1,5MHz angezeigt.
>
> Dadurch dauert das Flashen über 6 Minuten bei einem 32Mbit XCF32P

Nicht -H Bausteine koennen maximal 2 MBaud, aber mit besch.ss.n.r 
Kurvenform. 1500k ist die Obergrenze. In cablelist.txt ist auch eine 
Obergrenze angegeben, fuer 'ftdi' 1500k.  Steht auch oben im Ausdruck. 
Selbst mit MSPPE des FTDI gibt es noch viel Overhead, 100 k/s ist doch 
dann gar kein schlechter Wert.

Sebastian schrieb:
> Kannst Du die JTAG Geschwindkeit vom FTDI Chip noch beschleunigen. Diese
> ist nur auf 1,5Mbit eingestellt. Dies geht locker mit 10 oder 15Mbit.
> Nur leider bringt es nichts wenn ich den Wert verändert. Dies hat leider
> keinen Einfluss.

'ftdi' kann FT2232L oder FT2232H sein. VID/PID sind gleich, die 
Unterscheidungsmerkmale liegen viel tiefer. Also Begrenzung auf 1500k, 
die der FT2232L noch vernünftig kann. Abhilft:Eigenes Kabel definieren, 
und wenn es verbreitet ist, eine Patch senden.

Der Die H Bausteine koennen zwar bis 8000 k vernünftig, aber falls 
häufig schlägt auch die USB Latenzen beim umschalten zwischen Schreiben 
und lesen zu. Dann hilft blosse Übertragungsgeschwindigkeit auch nichts.

Aber es gibt inzwischen schon 3 "H" Modelle mit bis zu 30MBit

MPSSE.Multi-Purpose Synchronous Serial Engines (MPSSE), capable of 
speeds up to 30 Mbits/s, provides flexible synchronous interface 
configurations.

Daher ist es schade wenn man 6 Minuten warten muss um ein mcs File in 
den Xilinx PROM zu schreiben.

Kannst Du nicht eine Version kompilieren wo die Grenze auf 15MBit 
eingestellt wird.

Ich habe leider keine cablelist.txt in dem entpacken Ordner gefunden. 
Und ich habe mit diesem Compiler noch nie ein Projekt compiliert.

Sebastian schrieb:
> Benötigt man nur das mcs-file oder wird auch das cfi-file benötigt.
> Impact schreibt ja zum Beispiel die Checksumme in das cfi-file.
>
> Ich habe bis jetzt nur das mcs-file in den Ordner von xc3sprog kopiert

Es geht auch nur mit dem Bitfile oder auch mit einem Bin File. Du musst 
halt mit den Adressen aufpassen. Ich habe noch nie einen XCFxxP 
verwendet, der Algorithmus ist von jemand anderen. Ein Blick in die 
Quellen und das SVN log hilft vielleicht weiter.

Sebastian schrieb:
> Ich habe leider keine cablelist.txt in dem entpacken Ordner gefunden.
> xc3sprog
...
   -D        Dump internal devlist and cablelist to files

Dann die Liste anpassen und wenn xc3sprog im gleichen Verzeichnis liegt, 
wird die angepasste Datei verwendet.Ich habe leider keine cablelist.txt 
in dem entpacken Ordner gefunden.

> Und ich habe mit diesem Compiler noch nie ein Projekt compiliert.

Ich nehme gerne Patches für andere Compiler an...

Ich habe die Frequenz für den FTDI von 1,5MHz auf 15MHz angepasst. Jetzt 
dauert der Downloader anstelle von 6 Minuten nur noch 3 Minuten.

Ich hätte jedoch ca 37 Sekunden erwartet.

Ich werde es noch mal mit 30MBit versuchen.

Wenn ich auf 30MBit stelle benötigt er genauso viel Zeit. Demnach 
scheint noch die Handbremse angezogen zu sein.

Uwe Bonnes schrieb:
> Das ist die SVN Revision des xcs3prog.cpp files. Wenn jemand einen
> besseren Vorschlag hat, bitte...
Evtl. kannst Du svnversion verwenden um die Revisionsnummer zu 
erzeugen:

1

~/xc3sprog$ svnversion

2

709

Duke

Sebastian schrieb:
> Wenn ich auf 30MBit stelle benötigt er genauso viel Zeit. Demnach
> scheint noch die Handbremse angezogen zu sein.

Das mit dem USB Turnaraound zwischen Schreiben und Lesen hast Du 
verstanden? Und wenn Du willst, kannst Du das ganze auch noch auf 
asynchrone USB Transfers umstellen. Habe ich irgendwann nochmals vor, 
aber nicht im Moment.

Musst Du ueberhaupt den ganzen Flash neu schreiben? Evt hilft 
sektorweises Schreiben und Loeschen (...:W:... statt ...:w:...). Ist 
aber nur grob getestet.

Duke Scarring schrieb:
> Evtl. kannst Du svnversion verwenden um die Revisionsnummer zu
> erzeugen:~/xc3sprog$ svnversion
> 709
>
> Duke

Das ganze muss aber auch in den CMAKE Fluss passen, und lokal halte ich 
das Repository sowieso mit git.

Woher nimmst Du denn die Information über BTC, CCB und SUCR.

Stehen diese Infos im MCS-File?

Ich habe gelesen das die Infos im CFI-File stehen soll.



Wie wird das Verifying durchgeführt? Es werden die Daten zuerst in den 
FLASH kopiert und dann wieder ausgelesen. Die ausgelesenen Daten werden 
dann auf dem PC mit den gesendeten Daten verglichen. Oder wird das 
Verifying über eine Checksumme erledigt?

Sebastian schrieb:
> Woher nimmst Du denn die Information über BTC, CCB und SUCR.
>
> Stehen diese Infos im MCS-File?
>
> Ich habe gelesen das die Infos im CFI-File stehen soll.

Wie schon oben steht: "Ich habe noch nie einen XCFxxP
verwendet, der Algorithmus ist von jemand anderen". Wenn Du mehr wissen 
willst, dann musst und kannst Du an den Quellcode heran.

Wo liegt denn der Unterschied zwischen der "stripped" Version (0,4MB) 
und der unstripped Version (7.1MB)?

http://linux.die.net/man/1/strip

Auf jedenfall Danke für Deine Hilfe Bonnes

Peter S. schrieb:
> Dabei ist ein sog. Low Cost Download Cable für den Parallelport, welches
> mit älteren Impact (6) auch funktioniert.
> ...
> Kennt jemand Software, um dieses Kabel auch unter Linux zu nutzen?

Such mal nach cableserver (cblsrv). Ist aber Jahre her, das Zeug wird 
kaum noch sinnvoll unterstützt. Parallelport würde ich nicht mehr 
verwenden.

Zu Frage 1: die JTAG I/Os sind 3.3V-tolerant und bei xc3sprog kannst du 
VID/PID angeben, also: Alle FT2232H-basierenden Adapter funktionieren 
prinzipiell. Was das Verkabeln angeht, muss man einfach dran denken, 
dass der TDI am FT2232 ein Ausgang (TDO also Eingang) ist, siehe FT2232 
datasheet. Also TDO (FTDI) <-> TDO (FPGA), nicht wie beim Chaining (TDO 
-> TDI).

Peter S. schrieb:
> ok. Danke.
>
> cablesrv braucht GPIO's. Schönes Bastelprojekt:
> http://axio.ms/projects/wrtag/
>

Das Cableserver-Zeug mit IMPACT ist leider per Design ein Murks, Xilinx 
hatte da nicht so die glückliche Hand. Für Massenproduktion nicht zu 
gebrauchen. Dazu kommt, dass die langsame 'slew rate' der Parallel-GPIOs 
ab und mal beim bit-ge-bangten TCK Fehler produziert.

>
> Da gehe ich aber lieber mit der FT2232 Lösung.
> Die 'Verkabelung zw. FT2232 Adapter und Jtag ist mir trotzdem unklar!
>

Siehe PDF. Und guck ins FT2232H Datasheet, da kann man ansich nichts 
falschmachen. Nur GND nicht vergessen :-)

Peter S. schrieb:
> Auch wenn der Beitrag schon älter ist, passen meine Fragen hier doch
> ganz gut rein.
Neue Frage und Link auf den altem Thread wäre etwas besser gewesen.


> Ich habe 2 Fragen, die nichts miteinander zu tun haben, deshalb versuche
> ich sie zu trennen. Beide betreffen aber das Spartan3 Starterkit von
> Xilinx mit Spartan3 200k und xcf02s Prom.

Hast Du dieses Board?
https://www.xilinx.com/support/documentation/boards_and_kits/ug130.pdf

Auf dem Nachfolger-Evalboard mit dem Spartan 3E ist der (USB-)Programmer 
schon mit drauf.


> Dabei ist ein sog. Low Cost Download Cable für den Parallelport, welches
> mit älteren Impact (6) auch funktioniert.
> Nicht aber z.B. mit ISE 14.7.
Du kannst ja das neuere ISE mit dem älteren Impact nutzen.
Impact gab es auch als separaten Download (LabTools).

> Ist die Schaltung dazu in etwa/genau so wie hier beschrieben?
Ja, einfach nur ein paar Gatter als Treiber. Mutige (kein ESD-Schutz) 
können die Leitungen/Signale auch direkt verbinden.

Duke

Peter S. schrieb:
> Hat xc3sprog das mal unterstützt und es wurde später rausgenommen?
> Oder ist das ein Fork, der für Low Cost Kabel umgebaut worden ist?
Um das herauszufinden könnte man die Quellen vergleichen oder beim Autor 
nachfragen.

Wenn die Version bei Dir funktioniert, ist doch alles fein.
Die Parallelportvarianten machen JTAG per bit-banging. Möglicherweise 
ist einfach die Pinbelegung und logische Signalzuordnung  bei allen 
identisch, so das es klappt.
In dem Xilinx-PP-Kabel sind maximal Pegelwandler und Schutzbeschaltung 
drin, aber keine Logikschaltung.

Duke

Mit aktueller libftdi geschieht das Entladen der geladenen Module 
automatisch.
Wenn Du Dich zu Mitglied der Gruppe machst, der das USB Device gehoerst, 
brauchst Du auch nicht mehr das "sudo"

Hi.
ok. Danke.

Frage: Wo kann ich aktuellere TAR Container des Sourcecodes 
herunterladen?
Auf Sourceforge finde ich:
xc3sprog_792.git.tar.bz   2017-08-16   13.3 MB <-?? Git Repo
build-win32_rev780_stripped.tar.gz 2015-12-24   1.3 MB   <-win32 Bin
xc3sprog-0.0-svn685.armhf.deb   2012-09-05   955.4 kB<-arm Bin
xc3sprog-r401.tar.gz <- r401 Binaries (win32/lin32/lin64)
Im Verzeichnis xc3sprog liegt r216 als TAR Archive.

Unter Linux+win32 reichen mir auch die Binaries aktuell.
Aber: Es gibt da noch so ein "totes Pferd" = PowerMac G5 mit Ubuntu 
16.04, auf dem konnte ich r216 compilieren mit kleineren Anpassungen 
(#include <stdio.h>; typedef ... uint8/16/32_t). (Ich weiß - ein bischen 
sehr Retro)

r216 kennt aber z.B. -J <Hz> nicht.

detectchain zeigt jtag chain einwandfrei an. xc3sprog -c ftdi <bin> 
läuft aber gefühlt viel zu schnell durch und das fpga board bleibt 
mitten drin 'stehen' (alles nur Vermutungen).

Ideal wäre, wenn man einige Stufen zw. r216 und r792 als tar Container 
auch in Sourceforge ablegen könnte.

Peter

Aua, sourceforge scheint gerade mit dem Project oder allgemein Probleme 
zu haben. Ich kommen gar nicht mehr an der SVN Repo ran...

https://github.com/UweBonnes/xc3sprog.git