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.
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
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.
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.
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
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
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.
Bild_000.png
(12 KB)
