Hallo UWE, die letzte Version 733 die besitzt einne Bug. Das Uploaden der Firmware wird nicht bis zum Ende ausgeführt. Es wird jedoch nicht angezeigt das das Flashen abgebrochen wird. Erst bei der Prüfung wird festgestellt das etwas nicht in Ordnung ist. Ich habe mehrfach unterschiedliche Datein versucht in den FPGA als auch in den PROM (XCF16P) zu schreiben. Der Schreibvorgang bleibt immer an der selben Adresse hängen (siehe Schreenshot) Mit der Version 727 und der optimierten schnelleren Version vom 15.02.2013 funktioniert das Flashen fehlerfrei.
Im Trunk steht das es sich um Revision 738 handelt, wenn man jedoch die Software ausführt ist es die Revision 733.
schreib mal ne PN an Uwe Bonnes (uwebonnes), der ist der Entwickler.
Wie waere es, mal selbst in des SVN/GIT Log zu schauen? Abbruchbedingungen sind Glueckssache... Und hardwarenahe Programmierung ohne Zielhardware auch...
Was muss ich denn machen damit das Log-File erstellt wird? Wenn ich weiß wie ich das Log-File erstellen kann, dann poste ich gerne den Inhalt. Ich kann momentan leider nicht auf Sourcforge den Code anschauen. Es fehlt der Button "Code" somit komme ich nicht mehr auf die Seite Kannst Du schreiben ob Du einen Fehler gefunden hast? Ich werde die neue Version Montag gleich mal testen
Schau mal direkt hier: http://xc3sprog.svn.sourceforge.net/viewvc/xc3sprog/ (bei mir ist der Code-Knopf da, zumindest jetzt gerade. Vielleicht Ad-Blocker oder sonstiges Plug-In, welches hier Probleme macht?)
Kann mir jemand sagen, wie man die Version von XC3SPROg heraus bekommt, die gerade läuft? Die wird ja nicht mehr angezeigt.
1 | D:\hrt>xc3sprog -c ftdi -v hrt337.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 devlist.txt |
10 | Using cablelist.txt |
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 857.142 kHz from undivided clock |
14 | JTAG chainpos: 0 Device IDCODE = 0x39616093 Desc: XC95288XL |
15 | Device is blank |
16 | Programming Sector 107. |
17 | Programming time 15822.5 ms |
18 | Verify Sector 107 |
19 | Success! Verify time 14990.6 ms |
20 | USB transactions: Write 1953 read 1734 retries 0 |
Ne jetzt geht es wieder. Ich habe keinen Adblocker insatlliert. War wohl ein Problem der Homepage
@Uwe Mit der Version vom 3.3 funktioniert das Flashen wieder.
Kannst Du noch butte posten wie ich eine Log-Datei erstellen kann.
tt4u schrieb: > schreib mal ne PN an Uwe Bonnes (uwebonnes), der ist der Entwickler. Der richtige Weg ist es, einen Bug auf Sourceforge aufzumachen.
schorsch schrieb: > Kann mir jemand sagen, wie man die Version von XC3SPROg heraus bekommt, > die gerade läuft? Die wird ja nicht mehr angezeigt. Das habe ich in dem anderten xc3sprog thread geschrieben. Hier habe ich Testversionen gepostet, die Nummerierung gibt es nur bei Sourceforge Versionen.
Sebastian schrieb: > Woran hat es denn jetzt gelegen? Schau es Dir doch im SVN Log an. War ein * statt einem +.
Ich hätte gerne im SVN Log nachgesehn, aber es ist im Trunk nur eine 11 Tage alte Version 738 vorhanden. Aber es ist schön das Du den Fehler gefunden hast
Ich habe die Post noch mal überflochen und leider nichts gefunden. Benötige ich eine spezielle Version um ein Log-File zu erzeugen oder muss ich nur einen Parameter beim Aufruf von XC3SPROG übergeben.
> die Nummerierung gibt es nur bei Sourceforge Versionen. Soeben aus dem SVN gezogen und getestet: die 722 und 734 geben keine Versions-Nummern aus und die 738 behauptet, sie sei eine 724.
...weil diese SVN-Auto-Numerierung halt immer nur für ein bestimmtes File gilt und nicht für die HEAD Revision des gesamten Repos.
Christian R. schrieb: > ...weil diese SVN-Auto-Numerierung halt immer nur für ein bestimmtes > File gilt und nicht für die HEAD Revision des gesamten Repos. Daher nutze ich den Befehl 'svnversion' um die Revisionsnummer für das Projekt herauszubekommen:
1 | $ svnversion --help |
2 | usage: svnversion [OPTIONS] [WC_PATH [TRAIL_URL]] |
3 | |
4 | Produce a compact 'version number' for the working copy path |
5 | WC_PATH. TRAIL_URL is the trailing portion of the URL used to |
6 | determine if WC_PATH itself is switched (detection of switches |
7 | within WC_PATH does not rely on TRAIL_URL). The version number |
8 | is written to standard output. For example: |
9 | |
10 | $ svnversion . /repos/svn/trunk |
11 | 4168 |
12 | ... |
Duke
Ja das geht natürlich, ist aber ein ganzes Stück aufwendiger als die Ersetzung direkt im Quelltext mit den Platzhaltern.
Ich denke mal das Uwe noch eine Version erzeugen wird wo wieder eine Revision drin steht. Wir sollten nur noch mal testen ob die neue Version auch wieder zuverlässig funktioniert.
Ein Problem hatten wir noch wenn man direkt das Bit-File in den FPGA hochlädt, dann stürzt XC3SPROG ab. Dies könnten wir mal demnäcst angehen wenn Du zeit hast. Vielleicht könnten dies mal andere ausprobieren indem andere User die einen Spartan 6 oder Spartan 3 besitzen die Firmware direkt in den FPGA uploaden um dann zu sehen ob das immer der Fall ist oder nur bei einen Virtex 5 oder einen Windows 7 64Bit Betriebssystem
Wenn ich Zeit hab, teste ich das mal, ich hab vom Spartan 3 bis Virtex 6 alles da.
Sebastian schrieb: > Ein Problem hatten wir noch wenn man direkt das Bit-File in den FPGA > hochlädt, dann stürzt XC3SPROG ab. Hier nicht, weder mit der letzten .exe von Sourceforge (Rev. 691), noch mit der .exe aus dem Posting vom 3.3. > Vielleicht könnten dies mal andere ausprobieren indem andere User die > einen Spartan 6 oder Spartan 3 besitzen die Firmware direkt in den FPGA > uploaden um dann zu sehen ob das immer der Fall ist oder nur bei einen > Virtex 5 oder einen Windows 7 64Bit Betriebssystem Spartan-6, Win 7 64 Bit.
Durch Betriebssystem, FTDI Treiber und Adapter gibt es eine Menge Möglichkeiten. Ich hatte Sebastian auch schon eine ungestrippten Debug Build angeboten, bei dem ein Crash mit hoher Wahrscheinlichkeit hilfreiche Ausgaben macht. Aber er muss halt auf mich zukommen. Und hier poste ich kein 6 MByte Executable...
Sorry Bones, hatte die letzten Tage sehr viel zu tun. Muss bis nächste Woche den neuen Protitypen fertig haben. Kannst Du von der aktuellen Version die große 6MB Version erzeuegen und teste diese mal und poste die Ergebnisse.
Sebastian schrieb: > Sorry Bones, > > hatte die letzten Tage sehr viel zu tun. Muss bis nächste Woche den > neuen Protitypen fertig haben. > > Kannst Du von der aktuellen Version die große 6MB Version erzeuegen und > teste diese mal und poste die Ergebnisse. sach mal: Bist du eigentlich Student im Praktikum und willst spaeter mal Projektmgr werden? Lies dir mal deinen Post durch! Es gibt eine mailing-list fuer das Projekt, du sagst du haettest viel zu tun und dein Post liest sich so: Ach 'Bones', du hast ja sonst nix zu tun und bist sicherlich traurig, dass niemand zu deinem Programm Feedback gibt. Hier bin ich, nu mach mal mit meinen Sonderwuenschen! Du kommst mir vor, wie der 'pointy haired boss' aus Dilbert! Sorry, musste mal sein...
Ich kann das auch nicht richtig verstehen. Wenn ich Zeitdruck habe, nehm ich doch erst mal was fertiges. Xilinx braucht man sowieso um die Designs zu übersetzen, und da kann ich auch Impact in der Command Line nehmen. Da ist ja nichtmal eine akute Not für das open source Programm. Außerdem spricht man Leute in Deutschland entweder mit dem Vornamen oder mit Herr 'Nachname' an. Aber "Hallo Bones" jemanden an den Kopf zu werfen, der eigentlich Uwe Bonnes heißt...? Man was ganz anderes: Wer baut denn heutzutage noch ein neues Gerät mit einem Platform Flash? Das ding hat bis auf dem Ausleseschutz (der mi xc3sprog nicht programmierbar ist) quasi nur Nachteile.
Christian R. schrieb: > Wer baut denn heutzutage noch ein neues Gerät mit > einem Platform Flash? Hier! Ein uC/FPGA board das in winzigen Stueckzahlen (max. ein paar Hundert) hier intern in der Entwicklung verwendet wird. Da lernt man beim reflashen auch wenigstens die Kollegen und Kolleginnen kennen... Aber ich werde umstellen auf flashen via uC (incl. Bootloader damit ich den uC auch uebers Netz flashen kann).
Wir stellen alles auf SPI oder BPI Flash um, der ist wenigstens aus dem Design heraus programmierbar. Mit JTAG Debugger in China ist echt Murks...zum Glück nur einmal vorgekommen. Mit der AES Verschlüsselung geht das ja jetzt auch gut.
Christian R. schrieb: > Wer baut denn heutzutage noch ein neues Gerät mit einem Platform Flash? Kommt vor. Er ist einfach zu Programmieren (nicht unwichtig, wenn der Kunde das machen soll), das Flashen geht schneller (insbesondere wenn man auch noch den Umweg über ein SVF macht) und bei paralleler Anbindung ist das Konfigurieren auch schneller (wichtig z.B. bei den PCIe 100 ms). Letzeres wird allerdings durch die Quad-SPIs schon etwas entschärft. Für Feld- Wald- und Wiesen nehmen wir aber auch nur noch SPI.
Ich habe halt zuvor den Xilinx Platform Flash Programmer benutzt. Mein Chef wollte aber unbedingt das kurz vor Auslieferung der Geräte die Firmware auch übers Internet updatebar ist. Daher habe ich mich für XC3SPROG entschieden. Es sollte ja gut funktionieren. Da es dann so viele Probleme und Bugs gab hätte ich nicht gedacht. Den klar kann man ein SPI Flash benutzen, dieser ist auch sicherlich deutlich billiger und auch deutlich kleiner. Da ich jedoch auch die Mikrocontroller Firmware schreiben muss und zudem noch die PC-Software erstellen muss habe ich leider keine Zeit mich mit einem SPI Flash zu beschäftigen. Daher wollte ich das Risiko so gering wie möglich halten. Das mit dem Vornamen und Nachnamen ist mit nicht aufgefallen sorry UWE. Wenn man unter Dauerstress steht vergisst man schon mal die Höflichkeitsformen.
Sebastian schrieb: > Mein Chef wollte aber unbedingt das kurz vor Auslieferung... ...kein Kommentar... Sebastian schrieb: > Wenn man unter Dauerstress steht vergisst man schon mal die > Höflichkeitsformen. ...kein Kommentar... Open Source ist halt mal erst einmal kein Garant dafür, dass man auch (kostenlosen) Support in angemessener Zeit dafür bekommt. Warum auch? Der eine entwickelt in der Freizeit oder ehrenamtlich eine Software und andere wollen damit dann das (große) Geld verdienen. So gehts halt mal nicht. Lasst Geld springen, dann wird euch auch geholfen. Oder lasst es bleiben und arbeitet euch selber ein. Wenn es bei einem Kunden dann nicht funktioniert, ist (vielleicht) dann auch keiner (mehr) da, der euch dann hilft (zumindest in der von euch gewünschter Zeit).
Wieso installierst du dann nich die Xilinx LabTools und steuerst die über die Command Line? Die sind kostenlos und hätten dir jede Menge Arbeit und Stress erspart.
Ich dachte Open Source Projekte sind immer sol toll und alles funktioniert fehlerfrei im gegensatz zu kommerziellen produkten. Alle schwören doch auf Linux und Microsoft ist der letzte ... Wenn mam Code öffentlich zur Verfügung stellt dann sollte man auch darauf hinweisen ob es funktioniert oder nicht. @Christian Leider kann ich die LabTools nicht verwenden, da dies ein Xilinx Platform Kabel vorraussetzt zudem ist IMPACT nach der Installation fast 1GB. Man kann ja keinen Kunden zumuten das er das Gerät aufschraubt und dann den Xilinx Platform Flash anschließt und anschließend ein Firmwareupload durchführt. Schön ist doch wenn der Support aus dem Büro übers Internet auf den PC zugreift. Da unsere Gerät immer per USB an den PC angeschlossen ist kann man dann ohne Werkzeug die Firmware per USB flashen. Dies ist sehr praktisch. Wir werden auch eine eigene Software für das Flashen schreiben, aber zuvor muss ich noch einige anderen Sachen erledigen.
Sebastian schrieb: > Mit der Version 727 und der optimierten schnelleren Version vom > 15.02.2013 funktioniert das Flashen fehlerfrei. Warum bist du in der Eile nicht bei dieser Version geblieben und updatest dann in Ruhe nach dem Release auf 733? Hast Du mal probiert, ab welcher Version zwischen 727 und 733 der Fehler entstanden ist?
Achso, ihr habt den FTDI direkt eingebaut. Na dann hättest du aber auch z.B. urJTAG oder einen x-beliebigen anderen SVF Player für FDTI nehmen können, die können das auch dann indirekt über SVF programmieren. Aber naja, wenn´s jetzt klappt. Ich hab den xc3sprog in einen ähnlichen Projekt auch im Einsatz, da hängt ein Digilent Programmier-Adapter (SMTJTAG) an einem embedded Hub zum FW-Update. Ging aber mit einer hundealten Version schon problemlos mit dem Bit-File direkt in den Platform Flash.
Christian R. schrieb: > Achso, ihr habt den FTDI direkt eingebaut. Na dann hättest du aber auch > z.B. urJTAG oder einen x-beliebigen anderen SVF Player für FDTI nehmen > können, die können das auch dann indirekt über SVF programmieren. Aber > naja, wenn´s jetzt klappt. Ich hab den xc3sprog in einen ähnlichen > Projekt auch im Einsatz, da hängt ein Digilent Programmier-Adapter > (SMTJTAG) an einem embedded Hub zum FW-Update. Ging aber mit einer > hundealten Version schon problemlos mit dem Bit-File direkt in den > Platform Flash. Es ging ja auch schon am Anfang, nur war es recht langsam. Und ich denke, der SVF Player wäre nochmals langsamer gewesen, da hätte Sebastian wohl auch genölt. Sebastian schrieb: > Ich dachte Open Source Projekte sind immer sol toll und alles > funktioniert fehlerfrei im gegensatz zu kommerziellen produkten. Alle > schwören doch auf Linux und Microsoft ist der letzte ... > > Wenn mam Code öffentlich zur Verfügung stellt dann sollte man auch > darauf hinweisen ob es funktioniert oder nicht Wie soll ich den Kombinationen testen, die ich nicht habe? Da bin ich auf gutes Userfeedback angewiesen, mit Leuten, die auch den Biss haben, einen Fehler selbst einzukreisen und die vorgegebenen Kanäle benutzen. Sebastian meinte aber statt auf der Sourceforge Gruppe hier posten zu müssen. Das ich den Thread gesehen habe, war Zufall. Und bis ich aus Sebastian nützliche Fehlerbeschreibungen herausgebohrt hatte, das hat auch gedauert. Wenn ihm dann der Turn-around zu langsam war, dann werden nur wenige kommerzielle Produkte in so einen Fall schneller sein.
@ Christian Ich verwende auch einen Hub auf meinem Board. Dort ist an einem Port der FTDI angeschlossen. Ich hatte auch überlegt einen Digilent zu verwenden. Nur leider gibt es den SMT1 nur mit einer Micro USB Buchse. Dadurch kann ich die Platine nicht direkt an meinen HUB anschließen. Ich weis auch nicht warum Digilent keine Board to Board Version verkauft. @Uwe Es wäre schön wenn Du die fehlerhafte EXE-Datei in Sourceforge durch die aktuelle funktionierende Version ersetzt. Sonst laden einige noch die EXE-Datei runter und wundern sich warum es nicht funktioniert.
> Ich dachte Open Source Projekte sind immer sol toll und alles > funktioniert fehlerfrei im gegensatz zu kommerziellen produkten. Alle > schwören doch auf Linux und Microsoft ist der letzte ... > > Wenn mam Code öffentlich zur Verfügung stellt dann sollte man auch > darauf hinweisen ob es funktioniert oder nicht. @Sebastian Wenn Du XC3SPROG startest, bekommst Du den Hinweis: "If you contribute nothing, expect nothing" Ich finde es einfach toll, dass sich Leute wie Uwe die Mühe machen, ihre Ideen und Programme kostenlos der Öffentlichkeit zur Verfügung zu stellen. Es war gut von Dir, dass Du auf Probleme im Programm hingewiesen hast, aber manchmal kann Dein Ton schon ganz schön fordernd sein, da hörte man im Hintergrund ein "komm endlich und mach schon". Und das hat Uwe sicher nicht nötig, ich finde es einfach klasse, was er für uns alle macht. Und wenn er keine Lust mehr hat und aufhört, weil es zu viele Meckerer gibt, dann darf man ihm trotzdem nicht böse sein.
Bitte 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.