Announcement: there is an English version of this forum on Hallo Leute, es scheint eine neue Version (Version 720) von XC3SPROG zu geben. Dort kann man jetzt die Übertragungsfrequenz deutlich erhöhen, so das das hochladen der Firmware nicht mehr so lange dauert. Nur leider gibt es noch keine EXE von der Version. Ich habe den UWE_BONES schon angeschrieben, aber leider noch keine Antwort erhalten. Ich habe in der Mailing List anchgeschaut. Die geht leider nur bis Dezember 2012 demnach denke ich das Uwe die Nachricht nie erhalten hat. http://sourceforge.net/mailarchive/forum.php?forum_name=xc3sprog-users Falls Uwe dies liest kannst Du uns sicherlich schreiben wie weit die Umsetzung fortgeschritten ist. Falls Du mit der Umsetzung fertig bist kannst Du dann bitte auch eine EXE Datei daraus erzeugen.
Such mal hier im Forum, die Exe hat Uwe mal gepostet. ich hab die auch irgendwo auf Arbeit kann ich notfalls morgen mal raussuchen. Die hatte aber intern eine andere Version, 696 glaube ich. Speed lässt sich über die cablelist.txt einstellen.
Es git aber inzwischen schon eine eine Version die für die FT2232H Chips ist. Da kann man maximal 30MHz als JTAG Frequenz einstellen. Dadurch sollte es deutlich schneller gehen. Ich versuche gerade den -s Parameter zu verwenden leider finde ich in der Beschreibung kein Beispiel. Ich habe es jetzt wie folgt probiert. xc3sprog -c ftdi -L -v -s USB <-> Serial Converter test.mcs:w::MCS Dies funktioniert aber nicht. Wenn ich den -s Parameter weglasse dann funktioniert der Firmwareupload. xc3sprog -c ftdi -L -v test.mcs:w::MCS
Sebastian schrieb: > Es git aber inzwischen schon eine eine Version die für die FT2232H Chips > ist. Da kann man maximal 30MHz als JTAG Frequenz einstellen. Dadurch > sollte es deutlich schneller gehen. Gehts auch. Wie gesagt ich hab die Version hier aus dem Forum und verwende die mit dem Digilent Programmer. Da kann ich bis zu 30Mhz über die Cable-Datei einstellen. Probier mal die Datei: Beitrag "Re: xc3sprog: falscher IDCODE"
Sebastian schrieb: > Ich habe in der Mailing List anchgeschaut. Die geht leider nur bis > Dezember 2012 demnach denke ich das Uwe die Nachricht nie erhalten hat. Wenn keiner auf der Mailingliste postet, dann koennen auch keine neuen Beiträge im Archiv erscheinen.
Christian R. schrieb: > Such mal hier im Forum, die Exe hat Uwe mal gepostet. ich hab die auch > irgendwo auf Arbeit kann ich notfalls morgen mal raussuchen. Die hatte > aber intern eine andere Version, 696 glaube ich. Speed lässt sich über > die cablelist.txt einstellen. Beitrage in der xc3sprog Mailingliste landen in meiner mbox, hier lese ich nur von Zeit zu Zeit.
Sebastian schrieb: > Ich habe es jetzt wie folgt probiert. > > xc3sprog -c ftdi -L -v -s USB <-> Serial Converter test.mcs:w::MCS Mal mit Anführungszeichen probieren: xc3sprog -c ftdi -L -v -s "USB <-> Serial Converter" test.mcs:w::MCS
Eine neue Kabelbeschreibung kann man auch selbst erzeugen. - Im Verzeichnis wo xc3sprog steht, mit "xc3sprog -D" die internen Listen "dumpen" - Die gewünschte neue Beschreibung einfügen - Xc3sprog neu starten. Steht im Startverzeichniss eine cablelist.txt, hat die den Vorrang vor der internen Liste. Ebenso kann man mit der Umgebungsvariablen CABLEDB eine cableloist.txt vorgeben. Das Format der Beschreibung ist in cablelist.txt in den Quelle beschrieben: # OptString for ftdi: # VID:PID:PRODDESC:INTERFACE:DBUS_DATA:DBUS_EN:CBUS_DAT:ACBUS_EN Die nötigen Daten bekommt man mit lusub -v, VID = idVendor PID = idProduct PRODDESC = iProduct und dem Schaltplan der Dongles/ dem Datenblatt der FTDi Bausteines INTERFACE : Kanal bei FT2232x/FT4232 (hier mit X als Platzhalter) Viele Dongles haben noch Datenpuffer zwischen dem FTDI und dem Ausgang, und der Puffer muss evt. aktiv geschaltet werden. Das muss man mit den WertenDBUS_DATA:DBUS_EN:CBUS_DAT:ACBUS_EN angeben. Die an JTAG beteiligten Pins XDBUS0-XDBUS3 braucht man nicht zu berücksichtigen. Muss man z.b auf XCBUS5 eine NULL anlegen wird der String dann 0:0:0:0x20 Ein Blich in die MPSSE Beschreibung AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf hilft weiter. DBUS_DATA:DBUS_EN:CBUS_DAT:ACBUS_EN wird in die Befehle Set Data Bits Hihj/Low Bytes umgesetzst. Mehr dazu auch in xc3sprog.1 in den Quellen. Wenn die neue Kabelbeschreibung von allgemeinen Interesse ist, dann bitte die Beschreibung an die Liste schicken.
Danke für die Beschreibung. Ich habe mich am Anfang sehr schwer getan welche Kabelbeschreibung die rictige ist. Daher wäre es schön wenn für den ft232h, ft2232h und den ft4232h eine seperate Kabelbeschreibung vorhanden ist. Zudem wäre es auch schön wenn diese 1,5MHz Beschränkung für diese 3 Modelle erhöht wird. So wie ich es verstanden habe kann ich mit -J keine höhere Übertragungsfrequenz einstellen als die im maximal hinterlegte Frequenz in der Kabellist. So das ich eine neue Kabelliste erzeugen muss, aber genau dies schreck die meisten am anfang ab weil man nicht so tief in der FTDI Chips drin steck. Außerdem würde ich für den ft2232h und den ft4232h je 2 seperate Einträge erzeugen, da diese Bausteine ja je 2 JTAG Schnittstellen besitzen (Channel A und Channel B) Die Überflüssigen Einträge in der Liste können dann entfernt werden. Wenn man dann die Hilfe ausführt xc3sprog -h sollten dann auch diese Kabel angezeigt werden.
Ich habe mal im Anhang die aktuelle Kabeliste angehängt. bbv2 und bbv2_2 sind überflüssig, da es sich um den ft2232h handelt. bbv2 ist der Channel A vom FT2232h und bbv2_2 ist der Channel B vom FT2232h Dies könnte man doch besser lösen indem man diese beiden löscht und dann einen Eintrag ft2232h_mpsse_a und ft2232h_mpsse_b oder ft2232h_ch_a und ft2232h_ch_b hinzufügt. Zudem kann man dann auch gleich das Kabel "ftdi" und ftditest entfernen. Das gleich gilt dann auch für den ft4232h. Der ft232h besitzt nur 1 MPSSE Kanal Schön wäre auch wenn es einen neuen Parameter z.B. den -C gibt. Dieser zeigt dann die Kabeliste an. xc3sprog -C
Naja, wer XC3SPRog benutzt, ist im Normalfall kein Anfänger und auch niemand, der eine out-of-the-box Software erwartet. Da ist es ja nun wirklich keine schwere Sache, die Kabelliste zu exportieren, seinen Kram reinzuschreiben und gut.
Wenn man schon sachen besser machen kann dann sollte man dies auch tun. Was man auch in Agrifff nehmen sollte ist diese Fehlermeldung mit der Checksumme. Ich erzeuge mit dem iMPACT aus meinem Bit-File ein MCS-File. Ich ich dies dann in den PROM schreiben will erhalte ich folgende Fehlermeldung: "incorret record checksum found in MCS file" Er startet das Flashen trotzdem und sag bei der Validierung auch das alles in Ordnung ist.
mcs auf den Platform Flash klappt nicht so recht. Nimm am besten das Bit-File. Was auch fehlt ist das setzen der readprotect Bits.
Christian R. schrieb: > Da ist es ja nun > wirklich keine schwere Sache, die Kabelliste zu exportieren, seinen Kram > reinzuschreiben und gut. Und wenn es von nicht nur speziellen Interesse ist, bitte auch die Änderung auch wieder zurückgeben. An Sebastian: Aber bbv2 ist etwas anderes als ein ft2232h_mpsse_a Treiber. bbv2 schaltet aktive Pin ADBUS4 nach Masse. Eigentlich ist der Eintrag fuer einen Blusblaster v2 bestimmt, mit der entsprechenden "product description". Nur habe ich keine bbv2 Dongle und noch niemand den String beigetragen, mit dem sich der Busblaster meldet. Für Dongles mit eigener PID, wie dem cm1, ist die Produktbeschreibung nicht wichtig. Aber für Dongles mit generischer PID schon. Ich erinnere an das Motto des alten M6809 Magazins: - If you contribute nothing, expect nothing!
bingo schrieb: > hat jemend schon eine Exe für win32 ? Arbeitet den niemand mit cmake/ MSVCC und win32 und kann mal Versuche mit den SVN Quellen anstellen und berichten? Die Abhängigkeiten von libusb und libftdi sind aber nicht ohne... Ich hänge mal ein exe von 1.2.13 ran, aber eigentlich gehört das Programm selbst kompiliert, um schnell eigene Anpassungen machen zu können.
Sehe ich das richtig das ich mit dem XC3SPROG keine MCS-Files in einen XCF32P schreiben kann sondern nur BIT-Files. Aber ich dachte man muss das BIT-File in ein PROM-Format (MCS) umwandeln damit dies dann in einem PROM gespeichert werden kann. Kann man auch ein reines BIT-File im XC3SPROG speichern?
> Sehe ich das richtig ... Im Prinzip nein. xc3sprog -v -c xxxx -p yyy <file.mcs>:w::MCS sollte auch gehen. Einfacher ist es aber, mit Bitfile ohne den Umweg über das MCS File zu gehen. Das Bitfile sollte man auch direkt in das FPGA laden können. Mit den Kombinationen, die ich hatte ging das auch. Aber ein Michael berichtet gerade, das bei ihm unter Windows mit XCF32P und XC5VLX30T das schreiben des Bitfiles in das FPGA zu Absturz führt.
Was für Vorteile hat es dann ein Bit-File in ein ein MCS-File umzuwandeln wenn ich auch das Bit-File direkt in den Xilinx PROM schreiben kann. Gibt es da zusätzlich Checksummen? Ich sehe nur das das MCS-File 3 mal so groß ist wie das Bit-File.
Sebastian schrieb: > Was für Vorteile hat es dann ein Bit-File in ein ein MCS-File > umzuwandeln wenn ich auch das Bit-File direkt in den Xilinx PROM > schreiben kann. Gibt es da zusätzlich Checksummen? Ich sehe nur das das > MCS-File 3 mal so groß ist wie das Bit-File. Das musst Du Xilinx fragen!
Ist dies jetzt eigentlich die neue Version wo ich die JTAG Frequenz mit -J 30000000 auf 30MHz für den FT232H, FT2232H und FT4232H stellen kann?
Wenn das in der Cablelist definiert ist kannst du auch so hohe Geschwindigkeiten einstellen. Das MCS File ist ein Intel Hex des BitFiles. Der Vorteil: Angabe von Adressen. In einem MCS File können nämlich mehrere Bit-Files enthalten sein, für Revisions am XCF beispielsweise, oder für MultiBoot bei den neuen FPGAs. MCS ging aber wie geschrieben bei mir auch nicht in den XCF.
Demnach kann ich kein Multiboot machen wenn ich nur das BIT-File in den PROM schreibe. Wenn ich das MCS-File in den PROM schreibe steht dann der zu guter letzt das Bit-File in den PROM oder wie funktioniert das? Das MCS-File ist ein Intel Hex File. Das heist es stehen Daten und Adressen drin. Im Bit-File sind ja nur die Daten vorhanden. Werden die Adressen dann über JTAG mit übertragen und der PROM werttet dieses Adressen aus und schreib die Daten dann in diese Adressen oder wie kann man sich das vorstellen? Besteht eine Chance das dies in naher Zukunft auch gefixt wird?
Im MCS File stehen Adressen mit drin, ja. Aber die werden vom Programmierprogramm entfernt und nur die Daten geschrieben. Mit den Adressen kann das Programmierprogramm aber wissen, wo an welche Stelle genau im Flash das File soll. Das ganze kannst du auch mit Bin Files oder sonstwas erreichen, das ist doch lediglich ein Container. Multiboot geht dann halt über Umwege, also meinetwegen aus dem MCS ein Bin-File erzeugen.
A: Kann mir jemand zusammengehörige Bit und Mcs Dateien für XCFP schicken, bei denen das Programmieren mit Bit funktioniert, und mit Mcs nicht B: Auch beim Bin file kann man eine Ladeadresse in der Kommandozeile übergeben C: Die Exe hier ist von Anfang Februar, die Version 720 im SVN ist von Mitte Dezember. Die Änderungen sollten dann eigentlich drinnen sein
Beim Bitfile wird dann einfach der Adresszähler auf dem PROM aktiviert und fortlaufend hochgezählt?
Uwe Bonnes schrieb: > A: Kann mir jemand zusammengehörige Bit und MCS Dateien für XCFP > schicken, bei denen das Programmieren mit Bit funktioniert, und mit Mcs > nicht Kein Problem. Das Bit-File lädt korrekt, das mcs file will gleich gar nicht:
1 | JTAG chainpos: 0 Device IDCODE = 0xf5059093 Desc: XCF32P |
2 | incorrect record checksum found in MCS fileRequested operation (offset 0, length |
3 | 4325766 bytes) exceeds PROM space (33554432 bits) |
4 | USB transactions: Write 7 read 4 retries 0 |
Insgesagt ist das Programmieren bei gleicher Taktfrequenz etwa um Faktor 5 langsamer als Impact über das Digilent Plugin auf dem gleichen JTAG Adapter.
Das mit der Geschwindigkeit ist mir auch schon aufgefallen. Diese ist deutlich langsamer. Wenn ich die Frequenz von 6MHz auf 15MHz erhöhe,dann bringt das in der Uploadgeschwindigkeit 0% Verbesserung. Ich habe jedoch den TCK nachgemessen, dieser ist wirklich 15MHz..
Mit libusb-1 und den Varianten könnte man asynchrones Lesen implementieren und vermutlich zumindestens schon mal den Faktor zwei gewinnen. Allerdings erscheint mir das Aufsetzten von libusb-1 oder Alternativen unter Windows nicht ohne. Hat jemand libusb-1 unter Windows schon am Laufen?
Die Variablenlaengen in bitfile sind jetzt eindeutig definiert und sollten bei den grossen MCS Files nun auch auf 32 Bit Maschinen funftionieren.
Uwe Bonnes schrieb: > Allerdings erscheint mir das Aufsetzten von libusb-1 oder > Alternativen unter Windows nicht ohne. Hm, die Digilent Software läuft allerdings auch über den normalen FTDI Treiber und ist min. Faktor 4 schneller als XC3SPROG. Kann aber auch sein, das Impact da irgendwelche optimierten JTAG Sachen macht...
Uwe Bonnes schrieb: > Die Variablenlaengen in bitfile sind jetzt eindeutig definiert und > sollten bei den grossen MCS Files nun auch auf 32 Bit Maschinen > funftionieren. Programmieren funktioniert damit, aber da ist noch was anderes falsch. Der FPGA bootet nicht, wenn man das MCS in den XCFP brennt...
-R macht doch nichts anderes, als direkt nach dem Programmieren den FPGA neu zu laden, oder? Der FPGA bootet auch beim Power-Up nicht aus dem Flash, wenn man das MCS rein lädt. Falls -R doch was anderes als erwartet macht, teste ich dann nochmal.
Hm, kann das sein, dass beim MCS File, das Bit-Swapping nicht korrekt behandelt wird? Header MCS Programmierfile:
1 | :10000000FFFFFFFF5599AA66040000000C00018065 |
Header Readback:
1 | :10000000FFFFFFFFAA995566200000003000800125 |
Irgendwas war doch mit verdrehten Bits beim MCS für den Platform Flash...da müsste ja die IHEX Option statt MCS eigentlich funktionieren...
Ja, da gibt es ein Kuddelmuddel. Die Manpage xc3sprog.1 sagt:
MCS Xilinx .MCS file format.
IHEX Intel HEX format. Also used by Xilinx PROMGEN when
writing MCS files. Default for XMEGA devices.
Wie man das Kuddelmuddel löst, ist mir nicht klar....
Erkennt die anhängende Version die Probleme und gibt sie bessere Hinweise?
Kann ich morgen erst gucken. Das mit dem MCS File ist wirklich blöde. Promgen macht bei -spi kein Bit-Swapping, ohne schon, weil die Platform Flahes das gerne hätten. Heute kurz vor Feierabend wollte er erst mal gar nicht mehr den Flash löschen, kam gleich Error -15 wenn ich mich recht erinnere.
Ich denke das Digilent schneller ist weil die Paketgröße anders ist. Der FT2232H besitzt zum Beispiel einen 4K Byte Buffer. Es werden aber immer nur 256Bit auf einmal an den FT2232H übertragen. Deshalb bringt es kaum Performance wenn ich den TCK auf 15MHz stelle. Dadurch werden die Daten zwischen FT2232H und PROM mit 15MHz übertragen aber halt nur 256Bits auf einmal. Dann kommt wieder eine lange Pause. Durch das schlechte Duty Cylce Verhältnis kommt man halt auf eine schlechte Datenübertragungsrate. Es würde viel schneller gehen wenn wenn die Paketgröße z.B. 256Bytes anstelle von 256 Bits ist. Da die Bit Files ja immer 2^n sind müste dies auch super funktionieren. Dies würde natürlich wenig bringen wenn die 256Bytes in den PROM geschrieben werden und dann die Checksumme berechnet wird. Fals die Checksumme falsch ist müste dann wieder das komplette Paket übertagen werden. Fals aber nach dem hochladen der Firmware einfach alles wieder zurückgelesen wird, dann ist die Variante mit der größeren Paketgröße deutlich von Vorteil.
Der FT232H besitzt eine 1k Byte Buffer und der FT4232H besitzt einen 2k Byte Buffer. Der FT2232H beseitzt den größten Buffer mit 4kBytes.
Was schön ist wenn die Startadresse und Endadresse in die geschrieben wurde auch ausgegeben wird. Die Endadresse sieht man ja auch zum Schluss. Zudem wäre eine prozentualer Fortschritt eine nützliche Funktion. Wenn man die Bit-Datei öffnet und diese einmal ausliest dann weis man ja wie viele Daten in den PROM geschrieben werden sollen. Dann kann ich auch ausgeben wie weit das FLASHEN prozentual fortgeschritten ist. write to EEPROM from 0x00000 to 0x1fffff write to 0x1feff to 0x1fffff (100%)
Sebastian, die Quellen von xc3sprog sind offen und z.B. für XCF und SPI gibt es schon die Fortschrittsanzeige. Ich habe hier kein XCFP und auch nicht vor mir so etwas anzuschaffen. Patches willkommen!
Hallo UWE, ist die Version für 32Bit compiliert? Falls Du es mit einem 64Bit compiler compilierst muss man aufpassen das die ein int nicht 32Bit ist sondern 64Bit. Du schreibst das es mit großen MCS Datein auf 32Bit Systemen zu Problemen kommt. Ich selbst verwende jedoch ein 64Bit Windows 7 und auch da habe ich das Problem Das Xilinx MCS-File entspricht dem Intel Hex-Format (32Bit) -->I32Hex. Ich denke das der Fehler hier ist. Mit 16Bit kann man 65535 Adressen darstellen und ein XCF32P PROM besitzt halt 2E6 Adressen
Sebastian schrieb: > Du schreibst das es mit großen MCS Datein auf 32Bit Systemen zu > Problemen kommt. Nein, ich habe geschrieben, das es Probleme gab. Mit den neuen Versionen hier sollten die Probleme behoben sein. Ist das bei Dir der Fall?
Sebastian: Hast du beim XCFP mal IHEX statt MCS ausprobiert? Ich konnte es leider heute nicht testen, irgendwie wollte der Digilent Adapter nicht mehr, auch über Impact nicht. Aber mit den gespiegelten Bits sollte es mit der neuen Version gehen, damit hat er zumindest nicht mehr abgebrochen.
Bei mit hat der IHEX als auch der MCS nicht funktioniert. Ich werde mal morgen die neue Version ausprobieren. Es wäre schön wenn Bonnes mal schreiben könnte welche Parameter man nehemen muss. Muss ich nun MCS oder IHEX benutzen wenn ich mit iMPACT das MCS-File aus dem Bit-File erzeugt habe. Es ist ja schön das das Problem behoben wurde. Wie sicher kann man denn sein das es jetzt funktioniert? Immerhin hat er davor ja auch gemeldet das das MCS-File erfolgreich in den PROM geschrieben wurde.
Sebastian schrieb: > Muss ich nun MCS oder IHEX benutzen wenn ich mit iMPACT > das MCS-File aus dem Bit-File erzeugt habe Kommt drauf an, ob das MCS File für einen Xilinx Platform Flash oder für einen SPI Flash erzeugt wurde. Promgen dreht bei Platform Flash die Bits, bei SPI nicht. Ich hab das ja durch auslesen verglichen, das File war erfolgreich im Flash, aber halt mit gedrehten Bits, siehe mein Posting mit den beiden hex Ausschnitten weiter oben.
Also wenn ich jetzt ein XCFXP von Xilinx benutze dann muss ich IHEX oder MCS benutzen?
IHEX. Aber in der Zeit, in der Du die Frage gestellt hast, hättest Du das auch selbst probieren können und mit einem guten Bericht, was passiert ist und welche Fehler evt aufgetreten sind, oder einer Bestätigung, dass es geht, endlich mal selbst hier etwas beitragen können. Und wenn es nicht geht, dann les halt das Muster wieder aus dem PROM aus. Vergleiche es mit dem ursprünglichen Muster und ziehe daraus Schlüsse und Berichte ggf.
Ich teste gerade mit IHEX. Ich muss noch dringend einen Vortrag vorbereiten und hänge schon total in der Zeit hinterher. Deshalb kann ich bis nächsten Mittwoch leider auch nicht besonders viel testen. Momentan spiele ich eine MCS-File in einen XCF16P PROM von Xilinx. Das dauert nur immer so ewig fast 7 Minuten. Eigentlich sollte so ein 16MBit Flash wenn dam Daten mit 16MHz reinschreibt ja auch in 1 Sekunde beschrieben sein. Geben wie noch ein bischen Reserve (Faktor 3 drauf) dann sollte nach 4 Sekunden alles erledigt sein aber doch nicht 7 Minuten. Blos weil die Paketgröße nur 32Byte groß ist. Kannst Du das für die FT232H, FT2232H und FT4232H Modelle nicht verbessern? Kannst Du vielleicht mal genauer beschreiben wo genau nun der Fehler bei den großen MCS-Datein lag? Wurde die Datei falsch ausgelesen?
Sebastian schrieb: > Kannst Du vielleicht mal genauer beschreiben wo genau nun der Fehler bei > den großen MCS-Datein lag? Hast Du den nicht den Thread hier mitverfolgt? Sebastian schrieb: > Was schön ist wenn die Startadresse und Endadresse in die geschrieben > wurde auch ausgegeben wird. Du verwendest die -v Option und erhälst keine Ausgabe? Der Quellcode sagt etwas anderes. Sebastian schrieb: > Das > dauert nur immer so ewig fast 7 Minuten. Warum programmierst Du den so häufig? Lade zum Testen den Code nur in FPGA und und nur wenn alles so weit funktioniert in das Prom. Sebastian schrieb: > Eigentlich sollte so ein 16MBit Flash wenn dam Daten mit 16MHz > reinschreibt ja auch in 1 Sekunde beschrieben sein Und die EEPROM Seiten brauchen keine Erase Time und die Speicherzellen keine Programming Time? Wie oben beschrieben ist der Faktor 4 oder 5 drinnen, aber kein faktor 20.
Es wird schon mal nicht mehr folgender Fehler angezeigt "incorrect record checksum found in MCS fileRequested operation" Ich habe das MCS-File in den XCF16P mit dem Parameter IHEX geschrieben und die Done LED leuchtet auch nach dem Einschalten. Anschließend habe ich das MCS-File mit den Parameter MCS in den XCF16P geschrieben und wie zu erwarten war bleibt die Done LED aus. Auch die Firmware funktioniert dadurch nicht. Jetzt ich werde die auch noch mal mit einem XCF32P PROM ausprobieren, zudem habe ich da die Möglichkeit dies mit einem Xilinx Platform Cable zurückzulesen.
Sebastian schrieb: > ich > habe das MCS-File in den XCF16P mit dem Parameter IHEX geschrieben und > die Done LED leuchtet auch nach dem Einschalten. Dann ist doch alles in Ordnung...
Angehängte Dateien:
-
Bild_000.png
21 KB
Das direkte schreiben des Bit-Files in den FPGA hat bei mir immer Probleme bereitet. Ich habe dies aber noch nicht mit der neuen Version getestet. Ich benutze die -v Option. Nur leider steht nicht wirklich gut dargestellt von welcher Adresse bis zu welcher Adresse die Firware in den PROM geschrieben wird. dies könnte verbessert werden. Ich habe dies mal im Screeshot makiert. Man könnte das z.B. so gestallten: write Firmware to EEPROM adress 0x00000 to 0x1fffff actual writing status 0x1feff to 0x1fffff (100%) Ich denke bei Euch wird es sicherlich genauso sein wie bei uns Zeit kosten nun mal Geld und das nicht wirklich und wenn man da jedesmal 7 Minuten warten muss, dann wird man sich nach einer besseren Lösung umschauen. Denn wenn es auch mal in die Produktion geht, dann sind 7 Minuten viel zu viel, wenn es auch in 10 Sekunden geht.
Nicht das Du mich falsch verstehst. Das was die Software bis jetzt kann ist wirklich schoon gut. Jedoch sollte man sich auf einem gut nicht ausruhen sondern ein sehr gut oder fantastisch daraus machen. Ihr habt die Software ja auch geschrieben, damit diese möglichst viele Leute auch mal benutzen. Denn keiner schreibt eine Software gerne die dann keiner benutzt. Und da gehört auch ein wenig komfort dazu. Man kann z.B. auch beim IHEX dazuschreiben das dies für XPROM Files verwendet werden muss. Denn jeder denkt das man ein MCS-File mit dem Parameter MCS hochlädt
Sebastian schrieb: > dann sind 7 > Minuten viel zu viel, wenn es auch in 10 Sekunden geht 10 Sekunden? Was hast Du von den Loesch- und Programmierzeiten nicht verstanden, von denen ich oben geschrieben habe? Sebastian schrieb: > Das direkte schreiben des Bit-Files in den FPGA hat bei mir immer > Probleme bereitet Und, was sind das fuer Probleme? Ich kann wieder nur raten... Sebastian schrieb: > write Firmware to EEPROM adress 0x00000 to 0x1fffff > actual writing status 0x1feff to 0x1fffff (100%) Nachdem Du endlich einmal konkret geworden bist, habe ich das vergessene flush(stderr) im progalgxcfp entdeckt und ergaenzt...
Hallo Bones, ich weiß das das Löschen des PROMs mehr Zeit benötigt (ca 15s bei einem XCF16P) Aber der reine Schreibvorgang und die Verifizierung könnte um Faktor 20 schneller sein. Erzeug doch mal bitte eine Version wo nicht immer nur 32Byte an den FTDI Chip übertragen werden, sondern mal 256Bytes oder 512 Bytes oder 1024Bytes und dann kann ich das mal ausprobieren und gebe eine Rückmeldung. Ich weis nicht wie es momentan umgesetzt ist. Aber man könnte die MCS-Datei doch zuerst einmal öffnen und dann in den PC-Ram einlesen. Dann könnte man per Parameter einstellen wie viele Bytes ich pro Paket sinden möchte. (enum wäre hier vielleicht ganz gut 0 = 32Bytes; 1 = 64Bytes 2 = 128Bytes; 3 = 256 Bytes; 4 = 512Bytes und 5 = 1024 Bytes; 6 = 2048 Bytes) Was soll die neue Version besser machen? > write Firmware to EEPROM adress 0x00000 to 0x1fffff > actual writing status 0x1feff to 0x1fffff (100%) Nachdem Du endlich einmal konkret geworden bist, habe ich das vergessene flush(stderr) im progalgxcfp entdeckt und ergaenzt. es wird immer noch nicht die Startadresse angezeigt.
Sebastian schrieb: > Erzeug doch mal bitte eine Version wo nicht immer nur 32Byte an den FTDI > Chip übertragen werden, sondern mal 256Bytes oder 512 Bytes oder > 1024Bytes und dann kann ich das mal ausprobieren und gebe eine > Rückmeldung. Du forderst m.E. ganz schön viel, Freundchen. Ich fände es angebracht, wenn Du Deine Ansprüche zurückschraubst und mal was selber machst. Der Quellcode ist verfügbar! Duke
> Erzeug doch mal bitte eine Version wo nicht immer nur 32Byte an den FTDI > Chip übertragen werden, sondern mal 256Bytes oder 512 Bytes oder > 1024Bytes und dann kann ich das mal ausprobieren und gebe eine > Rückmeldung. Und, wie soll das mit dem Programmieralgorithmus klappen. Der Baustein nimmt nur Brocken von 32 Bytes/256 Bits" Aus ../Xilinx/13.4/ISE_DS/ISE/xcfp/data/xcf16p_vo48_1532.bsd -- Program Array Block0 - Optimized with LOOP polling feature "flow_program(array0) " & "INITIALIZE " & "(ISC_DATA_SHIFT 256:? wait TCK 1)" & "(ISC_ADDRESS_SHIFT 24:000000 wait TCK 1)" & "(ISC_PROGRAM wait 1.0e-3)" & "REPEAT 32767 " & "(ISC_DATA_SHIFT 256:? wait TCK 1)" & "(ISC_PROGRAM wait 10.0e-6)" & "loop min 1 max 100" & "((XSC_OP_STATUS wait 10.0e-6 5:06,1:1:OST,2:2))," & Sebastian schrieb: > es wird immer noch nicht die Startadresse angezeigt. Wirklich? Die Zeile "Programming frames ..." sollte für jeden Block aktualisiert werden. Aber nochmals die Frage: Wie stellst Du Dir vor, dass ich an einem Programmieralgorithmus Eingriffe am "offenen Herzen" mache, ohne die Hardware selbst zu haben? Den Algorithmus hat * Copyright (C) 2010 Joris van Rantwijk geschrieben. Wenn Du willst, das er etwas für Dich macht, dann musst Du auf der Mailingliste posten und hoffen, dass er einspringt...
Angehängte Dateien:
-
Bild_000.png
19 KB
Es ist keine Forderung sondern ein Ferbesserungs Forschlag. Hast Du schon mal in den Quellcode geschaut, genau das habe ich jetzt schon merfach getan und es ist sehr schwierig einen Überblick zu erlangen, da der Code schon sehr umfangreich ist. Uwe hat da viel mehr den Überblick. Die ersten ICs hatten halt nur 256Bit Speicher da machte es auch Sinn nur 32 Bytes an das IC zu übertragen, jedoch die heuten ICs besitzen deutlich größere Buffer. Und eine Performancesteigerung um Faktor 10 würde doch jeden freuen :-) @Uwe ich habe noch mal ein Screnshot angehängt. Ich sehe keinen Unterschied zwischen der neuen Version und der alten Version. Schön wäre es wenn hinter $Rev auch eine Version angezeigt werden würde so kann man sich nicht wirklich auch eine Version beziehen.
Sebastian, Du hast auch nicht auf meine Frage geantwortet, wass denn mit dem BitFile ins FPGA programmieren falsch laeuft. Das ist bei der Kommunikation mit Dir unzufreidenstellend.
Sebastian schrieb: > @Uwe ich habe noch mal ein Screnshot angehängt. Ich sehe keinen > Unterschied zwischen der neuen Version und der alten Version. Im Screenshot nicht. Der zeigt ja nur den Zustand nach der Programmierung an. Aber während der Programmierung sollte da die Zeile "Programming frames" hochzählen. Ich ändere gerade die Ausgabe an ähnlichen Stellen.
@ Uwe es ist richtig das der PROM mit nur 32Byte Paketen beschrieben werden kann. Doch besser ist es 256Bytes in den FT232H oder FT2232H zu schreiben. Dann stehen das z.B. bei 256Bytes 8 Pakete in je 32 Byte im FT2232H Speicher. Der FTDI arbeitet dann nach und nach die Pakete ab. Momentan schreist Du halt "nur" 1 Paket mit 32 Bytes in den FTDI Chip. Leider ist Windows kein Echtzeitbetriebssystem. Daher enstehen immer lange Wartenzeiten zwischen den Versenden von neuen Paketen. Wenn Du z.B. 1000 Pakete mit 32 Bytes nacheinander an den FTDI Chip sendest, dann hast Du z.B. 5ms x 62500 = 5 Minuten und 20 Sekunden Wartezeit die unnötig sind. XCF16P = 16MBit / 256Bit = 62500 Pakete mit je 32 Bytes (256Bits) Man kann das ja auch messen. Ob den JTAG CLOCK auf 6 MHz oder 15 MHz einstelle bringt 0 Performance. Die Zeit fürs flashen dauert genauso lange. Wenn man jetzt z.B. 256 Bytes überträgt dann müssen nur 7812 Pakete übertragen werden. Denmanch vergeringert sich die Wartezeit von 5 Minuten und 20 Sekunden auf 39 Sekunden.
Erstens: Jetzt hängen zumindestens schon 2 Fragen: - Gibt es die hochzählende Ausgabe und wenn nicht, warum - Was ist mit dem Bitfileprogrammieren Zweitens: - Bist Du sicher, das die Latenzen nicht durch irgendwelchen Einstellungen auf deinem Windowssystem beeinflussbar sind? xc3sprog selbst stellt minimale Latenz (1 ms) ein und triggert Senden explizit wenn das Programm etwas lesen muss. Drittens: - Schau Dir mal die MPSSE Machinen des FTDI an und die Programmieralgorithmen des XCFP. Nach dem Programmieren ist Warten angesagt, erst dann kann man den Status abfragen und danach muss man je nach Status unterschiedlich reagieren. Und dass willst Du mit einem vorgefertigten Kommando erschlagen?
Das mit dem hochzählen hat shon immer funktioniert. Jedoch ist das hochzählen so schnell das man die Startadresse nicht sieht. Wenn die Firmware gefaflasht wird dann interessiert einem ja in welchen Bereich die Firmware geschrieben wurde. Daher wäre es schön wenn es eine zusätzlich Zeile gibt. (klar habe ich keinen Offset eingestellt und somit sollte die Startadresse 0 sein) write Firmware to EEPROM adress 0x00000 to 0x1fffff actual writing status 0x1feff to 0x1fffff (100%) --> dies ist die hochlaufende Adresse und die funktioniert auch schon immer nur das leider keine Fortschrittanzeige vorhanden ist.
Der Algorithmus fuer XCFxxP hat mehrere Probleme: 1. Es wir immer das ganze Prom gelesen/gelöscht/programmiert/verifiziert 2 Auch kleine Verzoegerungen (25 us) werden mit jtag->Usleep() gemacht. Das bedingt unnötigeJTAG Roundtrips. Hat jemand Zeiten für das Programmieren von XCFP mit andere Adapter, wenn man den ganzen Baustein bearbeitet?
Angehängte Dateien:
-
Bild_000.png
43 KB
Ich habe das Bit-File in den Ordner kopiert in dem auch die XC3SPROG.exe vorhanden ist dann habe ich mit -p1 den FPGA anstelle des PROMS ausgewählt. ich erhalte sofort einen Fehler siehe Screepshot und das Programm beendet sich
Christian hat ja bereits weiter oben beschrieben das mit dem Digilent Adapter das ganze Faktor 4 schneller ist.
Ich glaube er benutzt diesen Downloader von Digilent http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,395,923&Prod=JTAG-SMT1 Auf diesen Downloader ist ein FT2232H von FTDI verbaut.
Sebastian schrieb: > Christian hat ja bereits weiter oben beschrieben das mit dem Digilent > Adapter das ganze Faktor 4 schneller ist. Wenn das File aber auch nur 1/4 des Bausteins belegt wäre der Faktor 4 erklärt...
Sebastian schrieb: > ich erhalte sofort einen Fehler siehe Screepshot und das > Programm beendet sich Nein, Du erhälst einen Fehler nachdem der Baustein programmiert wurde und das mit "Done" bestätigt hat. Ich kann Dir ein "ungestripptes" File schicken (6 MByte), dass sollte dann eine Backtrace erzeugen oder noch besser, Du lässt das Programm unter dem mingw Debugger laufen. Einem "Gast" kann ich aber keine PM schicken.
Ohje, Code, den man nicht selbst testen kann... In the jtga->usleep() implementierung scheint mir ein Vorzeichen vertauscht. Damit werden auch aus kurzen usleep(25) ein Win32 Sleep(0). Geht es jetzt schneller?
Angehängte Dateien:
-
Bild_001.png
17 KB
Es dauert jetzt deutlich länger. Mit der alten Version habe ich 182s benötigt um den Flash zu beschreieben. Mit der neuen Version benötige ich jetzt 655s etwa Faktor 4 so lang. Wie im Screenshot zu sehen steht da 3 mal die Rev in der Ausgabe. Die Revisionsnummern unterscheiden sich auch. Bei Erase Time und Write Time ist der Zeilenumbruch verloren gegangen.
Sebastian schrieb: > Wie im Screenshot zu sehen steht da 3 mal die Rev in der Ausgabe. Die > Revisionsnummern unterscheiden sich auch. Da stehen Revisionsnummern von xc3sprog und von progalgxcfp. Hast Du Dich schon mal mit SVN und automastisch generierten Revisionsnummern auseinandergesetzt? Das letzteres zweimal vorkommt ist seltsam, aber erstmak uninteressant. >Bei Erase Time und Write Time ist der Zeilenumbruch verloren gegangen. Gewollt, um die Ausgabe kompakt zu halten... Das exe jetzt versucht einen anderen Ansatz...
Angehängte Dateien:
-
Bild_000.png
20 KB
Das schreiben dauert jetzt wieder 185 Sekunden als genauso wie zuvor.
Uwe Bonnes schrieb: > xc3sprog > selbst stellt minimale Latenz (1 ms) ein und triggert Senden explizit Argh, das war auskommentiert. Mit dem Logikanalysator hat man bei Leseanfragen 1 ms Wartezeit gesehen, jetzt ist es 1 oder wenige Mikroframes (125 us). Neuer Versuch!
Angehängte Dateien:
-
Bild_000.png
11 KB
Gratulation UWE es funktioniert. Ich hatte zuvor mit einer JTAG Frequenz von 6MHz eine Downloadzeit von ca 180 Sekunden gehabt (XCF16P) Mit der neuen Version benötigte nur noch 44Sekunden. Dies ist schon eine deutliche Steigerung. Die MCS-Datei wird fehlerfrei in den Xilinx XCF16P geschrieben. Die Firmware funktioniert dann auch nach einem Neustart einwandfrei.
Ich habe noch mal zum testen die JTAG Frequenz auf 7,5MHz gestellt. Dies ist gegenüber 6MHz 25% schneller. Jedoch vergeringert sich die reine Schreibzeit nur von 44 Sekunden auf 42 Sekunden (5%). Wenn ich die JTAG Frequenz auf 10MHz erhöhe, dann bekomme ich beim Auslesen (-T1000 -v)der ID schon öfters Fehler, obwohl laut Xilinx DS123 die JTAG Schnittstelle vom PROM mit maximal 15MHz betrieben werden kann. Da scheint es noch ein Timing Problem zu geben.
Angehängte Dateien:
-
Bild_004.png
13 KB
Außerdem wenn ich die JTAG Frequenz auf 14MHz stelle dann wird die Frequenz auf 10MHz eingestellt. Ich weis nicht ob da noch ein Fehler bei der Berechnung der nächstmöglichen Frequenz ist oder ob diese bei hochen Frequenzen so ungenau wird.
Sebastian schrieb: > Jedoch vergeringert sich die reine Schreibzeit nur von 44 Sekunden auf > 42 Sekunden (5%). Versuche doch zu verstehen und selbst anzuwenden, was hier und in den Datenblättern b.z.w. 1532 BSDL-Dateien zu Lösch- und Programmierzeiten steht. Wenn man 64000 Sektoren schreibt, und für jeden Sektor die Programmierzeit bis zu einer ms ist, dann machen die Übertragungszeiten irgendwann nur noch wenig aus. Sebastian schrieb: > Außerdem wenn ich die JTAG Frequenz auf 14MHz stelle dann wird die > Frequenz auf 10MHz eingestellt. Ein Blick in das FTDI Datenblatt würde helfen! Wie willst Du aus 30 Mhz durch geradzahliges Teilen 14 Mhz erhalten? Sebastian schrieb: > Wenn ich die JTAG Frequenz auf 10MHz erhöhe, dann bekomme ich beim > Auslesen (-T1000 -v)der ID schon öfters Fehler, obwohl laut Xilinx DS123 > die JTAG Schnittstelle vom PROM mit maximal 15MHz betrieben werden kann. > > Da scheint es noch ein Timing Problem zu geben. So interpretierst Du Datenblätter? Denk noch mal nach! Sebastian schrieb: > Ich weis nicht ob da noch ein Fehler bei der Berechnung der > nächstmöglichen Frequenz ist oder ob diese bei hochen Frequenzen so > ungenau wird. Nochmals, die Quellen sind offen...
In der exe hier werden die kurzen wait Zeiten für die Programmieralgorithmen nun im FTDI durch entsprechend häufiges Toggeln von TCK gemacht. Damit spart man USB Rahmen und wird schneller.
Uwe Bonnes schrieb: >> Wenn ich die JTAG Frequenz auf 10MHz erhöhe, dann bekomme ich beim >> Auslesen (-T1000 -v)der ID schon öfters Fehler, obwohl laut Xilinx DS123 >> die JTAG Schnittstelle vom PROM mit maximal 15MHz betrieben werden kann. >> >> Da scheint es noch ein Timing Problem zu geben. > > So interpretierst Du Datenblätter? Denk noch mal nach! Was ist denn daran falsch? Ich habe noch nicht genauer im Datenblatt des FTDI Chips reingeschaut. Jedoch ist die maximale JTAG Frequenz 30MHz. Um diese zu erzeugen benutzt der FTDI einen PLL er kann ja auch immerhin Daten mit 480MBit übertragen. Demnach kann man auch aus 480MHz sicherlich 14Mhz erzeugen 480/14 = 34 Aber ich kann da noch mal am Mittwoch nachschauen ich muss noch dringend am Vortrag arbeiten
Sebastian schrieb: > Wenn ich die JTAG Frequenz auf 10MHz erhöhe, dann bekomme ich beim > Auslesen (-T1000 -v)der ID schon öfters Fehler, obwohl laut Xilinx DS123 > die JTAG Schnittstelle vom PROM mit maximal 15MHz betrieben werden kann. Wie ist die Drive Strength im FTDI EEPROM eingestellt? Mehr als 4 mA Treiberstrom könnte die Delays verkürzen.
Nee, die JTAG Frequenz kann nur aus den 30MHz erzeugt werden. Die 480MHz sind nur für den USB HighSpeed Teil. Im Datenblatt des FTDI stehn die Formeln drin. Die Zeiten sind doch spitze jetzt, schneller kann der rote Xilinx Programmer auch nicht programmieren, ein XCF32P mit einem Design für den XC4VLX60 braucht immer ca. 120 sek da, auch bei 12MHz JTAG Frequenz. Da gibts doch jetzt gar nichts mehr zu meckern. An der Erase Time kann man nicht drehen, die steht auch im Datenblatt. Beim XCF32P sogar ca. 30 sek für BULK Erase.
Christian, kannst Du bitte auch mal die Exe von 15.02.2013 11:42 ausprobieren? Wenn es geht, kann ich dann die Änderungen nach Sourceforge hochladen...
Ich habe leider keinen EEPROM am FT2232H daher kann ich leider die Strom für die JTAG Treiber nicht verändern stehen auf Standard (4mA). Sind die Flanke dadurch nicht steil genug? Muss ich den Treiber auf 16ma einstellen?
Angehängte Dateien:
-
Bild_000.png
11 KB
Die Zeit für das Flashen hat sich von 44 Sekunden auf 39 Sekunden vergeringert. Super Leistung Uwe. (JTAG Frequenz 6MHz) Das mit den Bit-File in den FPGA hochladen können wir vielleicht ja noch nächste Woche ab Mittwoch genauer untersuchen. Natürlich nur wenn Du auch Zeit hast.
Uwe Bonnes schrieb: > Christian, > > kannst Du bitte auch mal die Exe von 15.02.2013 11:42 ausprobieren? Wenn > es geht, kann ich dann die Änderungen nach Sourceforge hochladen... Leider nicht, ich hab jetzt erst mal bis 22. Februar Urlaub. Und zu Hause hab ich keine derartige Hardware. Aber ich denke, wenn unser Sebastian zufrieden ist, wird´s schon soweit OK sein. Auch von mir besten Dank, das erspart bei Updates im Feld durch den Kunden eine Impact Installation.
Sebastian schrieb: > Das mit den Bit-File in den FPGA hochladen können wir vielleicht ja noch > nächste Woche ab Mittwoch genauer untersuchen. Natürlich nur wenn Du > auch Zeit hast. Sollten wir im Auge behalten..
Ich will mich auch noch mal die die Mühe bedanken. Das Programm ist nun noch mal besser geworden, da bei den mcs Datein der Bug behoben wurde. Zudem hast Du die Performance auch noch um den Faktor 4 verbessern können. Ein dickes Danke.
Ich habe da noch ein Idee. Schön wäre es auch wenn es eine DLL geben würde, Dann kann ich für die Produktion auch ein kleines Programm mit Oberfläche erzeugen. Dazu benötigt man dann z.B. 3 Funktionen init_xc3sprog flash_xc3sprog destroy_xc3sprog Mit init erzeugt man dann eine Instanz von der xc3sprog Klasse und gibt einen Pointer zurück der auf die neue Instanz zeigt. Mit der Flash Funktion kann man dann die Daten und die Parameter übergeben. (Zeiger auf die Datei und Parameter wie -J -v -L und IHEX oder MCS) Die Funktion kann dann zurückgebenn ob alles Ok war oder ob ein Fehler aufgetreten ist. Die Destroy Funktion zerstörrt dann wieder die erzeugte Instanz. Ich weiß das ist eine Menge Arbeit und es wird ne menge Zeit in Anspruch nehemen, jedoch wäre dies eine Idee für die Zukunft, so hat man die Möglichkeit XC3SPROG in seine Software einzubinden. Kannst ja mal in Ruhe drüber nachdenken. Am Kontainer könnte ich mithelfen, da ich vor kurzen selbst einen DLL Kontainer erzeugt habe.
Hm, man kann doch auch eine Exe aus einem beliebigen Programm ohne Fenster aufrufen und den stdout umlenken. Also da brauchts doch keine extra DLL. Außerdem nochmal: Der Quelltext ist verfügbar, was genau hindert dich, dir daraus selbst das zu bauen, was du brauchst?
Ich habe mal versucht, den miniLA Mockup aus diesem Thread Beitrag "MiniLA Version MockUp" mit der letzten Version von xc3sprog zu programmieren, schlägt leider fehl:
1 | D:\minila\prg>xc3sprog -c ftdi -v state.jed |
2 | XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Windows |
3 | Free software: If you contribute nothing, expect nothing! |
4 | Feedback on success/failure/enhancement requests: |
5 | http://sourceforge.net/mail/?group_id=170565 |
6 | Check Sourceforge for updates: |
7 | http://sourceforge.net/projects/xc3sprog/develop |
8 | |
9 | Using built-in device list |
10 | Using built-in cable list |
11 | Cable ftdi type ftdi VID 0x0403 PID 0x6010 dbus data 00 enable 0b cbus data 00 data 00 |
12 | Could not open FTDI device (using libftdi): device not found |
13 | Using FTD2XX, Using JTAG frequency 1500000 from undivided clock |
14 | JTAG chainpos: 0 Device IDCODE = 0x39616093 Desc: XC95288XL |
15 | Device is blank |
16 | Programming Sector 0................................failed |
17 | Verify Sector 0 |
18 | Mismatch at fuse 15: 1 vs 0 |
19 | USB transactions: Write 75 read 39 retries 0 |
Mit der Version 483 von xc3sprog (die letzte, die ich sonst dafür nutze) geht es problemlos:
1 | D:\minila\prg>xc3sprog -c ftdi -v state.jed |
2 | XC3SPROG (c) 2004-2010 xc3sprog project $Rev: 483 $ OS: Windows |
3 | Free software: If you contribute nothing, expect nothing! |
4 | Feedback on success/failure/enhancement requests: |
5 | http://sourceforge.net/mail/?group_id=170565 |
6 | Check Sourceforge for updates: |
7 | http://sourceforge.net/projects/xc3sprog/develop |
8 | |
9 | Using Cable ftdi Subtype No enable "" |
10 | Using FTD2XX, Using FTDI Clock divisor 0x0001 |
11 | Using built-in device list |
12 | JTAG chainpos: 0 Device IDCODE = 0x39616093 Desc: XC95288XL |
13 | Device is blank |
14 | Programming Sector 107. |
15 | Programming time 22947.1 ms |
16 | Verify Sector 107 |
17 | Success! Verify time 16270.9 ms |
Bitte hangle Dich die hier geposteten Versionen durch und berichte, ab wann das Problem auftritt. Danke
> Bitte hangle Dich die hier geposteten Versionen durch und berichte, ab > wann das Problem auftritt. Gerne: 07.02. 16:28 ok 11.02. 12:35 ok 11.02. 17:50 ok 13.02. 22:57 ok 14.02. 13:08 ok 14.02. 14:38 ok 14.02. 18:40 ok 15.02. 11:42 geht nicht (siehe mein Posting von 18:33)
Nachtrag: JTAG Frequency ist bei den ok Versionen 1200000, bei der Version vom 15.02. 1500000 Brauchst Du evtl eine Hardcopy?
bingo schrieb: > P.S. Die Versionen im SVN geben teilweise keine Versionsnummern mehr aus Die Versionen hier wurden meistens in einem lokalen Git Baum (git svn clone) gebaut. Da wird $rev überhaupt nicht angefasst. In SVN muss sich das File selbst ändern, damit $rev angepasst wird. Die letzten Änderungen waren in ioftdi und progalgxcfp und haben xc3sprog selbst nicht berührt...
bingo schrieb: > Nachtrag: JTAG Frequency ist bei den ok Versionen 1200000, bei der > Version vom 15.02. 1500000 Bitte setzte doch man die JTAG Frequenz mit -J ... herunter. Und/Oder teste die Integrität Deiner JTAG Kette mit -T und verschiedenen JTAG Frequenzen. Ich möchte keinen Phantom hinterherlaufen. Kannst Du evt auch mal die Linuxversion testen? Auf eine Board hier kann ich nämlich mit der aktuellen Version kein Problem feststellen, auch bei mehrfachen Durchlauf, und auch mit libftd2xx >./xc3sprog -c ftdijtag -v test XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Linux Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop Using built-in device list Using built-in cable list Cable ftdijtag type ftdi VID 0x0403 PID 0x6010 Desc "FTDIJTAG" dbus data 00 enable 1b cbus data 00 data 00 Using Libftdi, Using JTAG frequency 1500000 from undivided clock JTAG chainpos: 0 Device IDCODE = 0x59608093 Desc: XC95144XL Device is blank Programming Sector 107. Programming time 10909.2 ms Verify Sector 107 Success! Verify time 420.8 ms USB transactions: Write 1954 read 1734 retries 2
Ich hab jetzt mal die Taktfrequenz heruntergesetzt, mit -J 1200000 immer noch Fehler, mit -J 1000000 gehts, darunter auch. Interessant finde ich die Unterschiede in den Zeiten (hier mit einem älteren Laptop und W2k): -J prog verify 1000000 13093 2125 800000 13109 1625 600000 13203 1640 400000 13312 2125 Getestet auf 2 verschiedenen Rechnern mit XP (QuadCore AMD) und W2k (alter Lappi). Ich habe zwar auch Ubuntu, mache damit aber nur Browser und anderes 0815-Zeugs ...
bingo schrieb: > Ich hab jetzt mal die Taktfrequenz heruntergesetzt, mit -J 1200000 immer > noch Fehler, mit -J 1000000 gehts, darunter auch. Hallo, was ist das für ein Adapter, welche Bauteile sind noch in der Kette? Ich habe unter Linux und Windows mit libftdi und ftd2xx bei 1.5 MHz getestet und keine Probleme gesehen. Läuft ein -T0 Test bei 1.5 MHz ohne Probleme?
Im miniLA-Mockup ist ein FT2232D verbaut, sonst hängt da nichts dran. Dein Programmier-Vorschlag ergab folgendes Ergebnis, nach 12 Stunden habe ich dann abgebrochen:
1 | D:\MINILA\PRG>xc3sprog -c ftdi -v -J 1500000 -T0 |
2 | XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Windows |
3 | Free software: If you contribute nothing, expect nothing! |
4 | Feedback on success/failure/enhancement requests: |
5 | http://sourceforge.net/mail/?group_id=170565 |
6 | Check Sourceforge for updates: |
7 | http://sourceforge.net/projects/xc3sprog/develop |
8 | |
9 | Using built-in device list |
10 | Using built-in cable list |
11 | Cable ftdi type ftdi VID 0x0403 PID 0x6010 dbus data 00 enable 0b cbus data 00 data 00 |
12 | Could not open FTDI device (using libftdi): device not found |
13 | Using FTD2XX, Using JTAG frequency 1500000 from undivided clock |
14 | JTAG chainpos: 0 Device IDCODE = 0x39616093 Desc: XC95288XL |
15 | Reading ID_CODE 2147483647 times |
16 | Sending 8 bits IDCODE Commands: 0xfe |
17 | Expecting 1 IDCODES : 0x39616093.............................................................................................................................................................................................................................. |
.
P.S. mit -J 1000000 -T gehts (dauert ca 1 Minute)
1 | D:\MINILA\PRG>xc3sprog -c ftdi -v -J 1000000 -T |
2 | XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Windows |
3 | Free software: If you contribute nothing, expect nothing! |
4 | Feedback on success/failure/enhancement requests: |
5 | http://sourceforge.net/mail/?group_id=170565 |
6 | Check Sourceforge for updates: |
7 | http://sourceforge.net/projects/xc3sprog/develop |
8 | |
9 | Using built-in device list |
10 | Using built-in cable list |
11 | Cable ftdi type ftdi VID 0x0403 PID 0x6010 dbus data 00 enable 0b cbus data 00 data 00 |
12 | Could not open FTDI device (using libftdi): device not found |
13 | Using FTD2XX, Using JTAG frequency 1000000 from undivided clock |
14 | JTAG chainpos: 0 Device IDCODE = 0x39616093 Desc: XC95288XL |
15 | Reading ID_CODE 10000 times |
16 | Sending 8 bits IDCODE Commands: 0xfe |
17 | Expecting 1 IDCODES : 0x39616093.......... |
18 | JTAG loc.: 0 IDCODE: 0x39616093 Desc: XC95288XL Rev: C |
19 | IR length: 8 |
20 | USB transactions: Write 10008 read 10005 retries 0 |
.
Riesenunterschied zwischen -T und -T0! -T läuft 10000 mal, -T0 bis der Benutzer das Programm beendet. Der Test zeigt aber keine reproduzierbaren Probleme in der Kette. Warum das Programmieren bei 1.5 Mhz bei Dir nicht klappt ist mir noch rätselhaft. Im Moment ist der Fehler bei Dir für mich noch nicht Grund genug, die Defaultrate in cablelist.txt herunterzusetzten. Ich habe aber eine Bug(Problem) Report im Sourceforge Projekt aufgemacht. Evt. hat es auch damit zu tun: Wenn man sich die TCK Pulsform beim FT2232D bei 3 oder 2 MHz anschaut, dann sieht man da grosse Asymetrien. Evt gibt es das in deutlich verringerter Form auch bei 1.5 Mhz und das führt dann beim Programieren zu Problemen. Ich behalte das Problem im Kopf, evt. kann man ja programmatisch bein Erkennen eine nicht "H" Adapters die Geschwindigkeit etwas heruntersetzten.
Angehängte Dateien:
-
tck.jpg
150 KB
Ich habe auch einen miniLA "Mockup" und kann die Probleme von bingo bestätigen. Mit -J 1500000 oder 1200000 geht es nicht mit der Version, die hier am 15.02. gepostet wurde. Ich habe mal mein (zugegebenermassen uraltes) Oszi an TCK gehängt, ein Rechteck sieht auch auf der alten Kiste anders aus. Ich werde mal einen Post im miniLA-Thread setzen, vielleicht haben andere miniLA-Nutzer auch schon Erfahrungen. Grundsätzlich ist das aber für uns kein Problem, denn man kann ja die cablelist.txt anpassen oder mit -J 1000000 arbeiten, der "Zeitverlust" ist bei der Anwendung verschmerzbar. Und an uwebonnes 1000000 Dank für sein Programm und sein Engangement!
Auf eine FT2232 Board mit AT90CAN128/ XCF04S/XC3S500E laueft ein -T0 Test auch bei 6 MHZ ohne Probleme. Ich habe in der Kabelliste jetzt einen Eintrag für den Minila gemacht, mit reduzierter Geschwindigkeit von 800 kHz. Eine Exe findet man im SVN. Hat der Minila ein EEPROM für den FTDI und definiert eine spezifische VID/PID oder Produkt description? Die kan ggf. auch aufnehmen, nur muss sie mitgeteilt werden...
Angehängte Dateien:
-
eeprom.png
29 KB
1 | idVendor 0x0403 Future Technology Devices International, Ltd |
2 | idProduct 0x6010 FT2232C Dual USB-UART/FIFO IC |
sind die Standardwerte für den FT2232D
Hallo zusammen, ich versuche gerade mit xc3sprog den SPI Flash über einen Spartan6LX9 zu programieren. Ich habe das nötige bitfile zuvor auf den FPGA geladen. danach schreibe ich auf den SPI Flash: xcs3prog -c ftdi -I top.bit ich bekomme folgende Meldung: JEDEC: c2 20 0x17 0xc2 unknown JEDEC manufacturer: c2 ISF Bitfile probably not loaded. Ich komme leider nicht mehr weiter, hat jemand eine Idee zur Lösung? Habe schon unterschiedliche Builds von xc3sprog probiert die ich finden konnte, evtl war noch nicht der richtige dabei? gruß Fabian
Hast Du eine Dokumentation zu Deinem Board? Ich würde prüfen, ob die JEDEC-ID mit dem vom verbauten SPI-Flash übereinstimmt. Duke
Fabian schrieb: > Hallo zusammen, > ich versuche gerade mit xc3sprog den SPI Flash über einen Spartan6LX9 zu > programieren. > > Ich habe das nötige bitfile zuvor auf den FPGA geladen. danach schreibe > ich auf den SPI Flash: > > xcs3prog -c ftdi -I top.bit > > ich bekomme folgende Meldung: > JEDEC: c2 20 0x17 0xc2 > unknown JEDEC manufacturer: c2 > ISF Bitfile probably not loaded. > > > Ich komme leider nicht mehr weiter, hat jemand eine Idee zur Lösung? > Habe schon unterschiedliche Builds von xc3sprog probiert die ich finden > konnte, evtl war noch nicht der richtige dabei? > Was fuer einen Speicher verwendest Du? Gib bitte die genaue Bezeichnung an. Und warum kaperst Du einen alten Thread?
Hallo, das Board ist das miniSpartan6+ LX9 von Scarab Hardware. Impact ist zu. Das Programieren funktioniert ja auf den FPGA, nur nicht in den SPI-flash. Und warum einen neuen Thread auf machen wenn es hier doch gut zum Thema passt?
Fabian schrieb: > das Board ist das miniSpartan6+ LX9 von Scarab Hardware. Was für ein Flash-Chip ist denn verbaut? Der SPI-Flash ist der kleine 8-Pinner, direkt neben dem Taster. > Impact ist zu. Das Programieren funktioniert ja auf den FPGA, nur nicht > in den SPI-flash. Kommst Du mit Impact auf den SPI-Flash? > Und warum einen neuen Thread auf machen wenn es hier doch gut zum Thema > passt? Na, nicht wirklich. Ein neuer Thread wäre schon gerechtfertigt gewesen. Duke
Hallo, der SPI Flash ist der 25l6445e. Mit IMPACT komme ich nicht auf den FPGA, da der FTDI Chip nicht von Impact unterstützt wird. Oder gibt es hier einen neuen Weg der das ermöglicht?
Hallo, das Problem ist endlich gelöst :-) die richtige version von xc3sprog ist xc3sprog_r771_untested.exe.zip :-) hier ist Macronix enthalten. der SPI-Flash lässt sich beschreiben, und der FPGA bootet wunderbar. dass die Versionen mit der Kennzeichnung "untested" immer doch die besten sind....
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.