Hallo! Ich habe einem USB-Seriell-Wandler mit einem FT232RL aufgebaut. Er wurde auch sofort vom PC erkannt, und ein erster Test mit RX auf TX gebrückt war auch erfolgreich, es kamen alle Zeichen wieder rein. Daher denke ich, dass die Hardware so weit in Ordnung ist. Nun wollte ich die CBUS-Pins einstellen, weil ich dort eine LED und einen P-MOSFET zum Schalten der Versorgung für meinen angeschlossene Schaltung angeschlossen habe. Außerdem habe ich den Strombedarf mit 500mA angeben, und die "USB String Descriptors" geändert. Dazu habe ich die aktuellste Version von FT_Prog (v1.2.6) benutzt. Nachdem ich die Einstellungen im FT23RL gespeichert hatte, wurde er nach dem nächsten Einstecken nicht mehr erkannt. Windows zeigt in als unbekanntes Gerät an, mit VID=0000 und PID=0000. Manuelles Installieren des Treibers klappt nicht, und auf nem zweiten Rechner geht es auch nicht. Insgesamt habe ich folgende Einstellungen verändert: Max Bus Power: 500mA USB String Descriptors, Manufacturer: UWEGW USB String Descriptors, Product Description: OPTO HA CBUS0: #SLEEP CBUS3: #TX&RXLED Die "USB String Descriptors" habe ich so verstanden, dass sie z.B. nur die Meldung beim Einstecken des Gerätes verändern, aber nichts mit der eigentlichen Identifizierung zu tun haben (das läuft ja über VID/PDI, die ich auf dem Standardwert gelassen habe). Im Handbuch zu FT_Prog ist nur erklärt, dass man bei einer eigenen VDI/PDI Einstellungen in den Treiberdateien was ändern muss, aber zu den Descriptors steht so ein Hinweis nicht. Und die anderen Einstellungen sollten ja die Erkennung durch den PC nicht verhindern. Die CBUS-Pins sind reine Ausgänge, und die maximale Stromaufnahme ist ja nur ne Information für den PC, damit er die benötigte Leistung kennt. Daher bin ich momentan etwas ratlos, wo mein Fehler liegen könnte. Die Schaltung entspricht der aus dem Datenblatt, Abschnitt 7.3. Die Schaltleitung für den FET (ein IRF7220) ist an CBUS0 angeschossen, eine LED an CBUS3. Weiß jemand, wie ich den FT232RL wieder ansprechen kann? mfg uwegw
7.3. verwendet keinen FET. Meinst du 6.3? Falls ja, hast du exakt die 6.3er Schaltung aufgebaut? Ralf
Kannst du ihn jetzt auch nicht mehr mit FT_Prog auslesen!? Vielleicht hast du ja auch versehentlich die Stromversorgung auf extern gestellt?
In meinem Datenblatt ist es die 7.3. Aber ich sehe gerade, das ist schon etwas älter. Da fehlt auch der Pullup am #PWREN-Signal. Der Pin liegt aber sowieso schon dauerhaft auf 5V... Im Anhang noch der komplette Schaltplan. FT_Prog erkennt den Chip auch nicht mehr. Die Spannungsversorgung des FT232RL kommt direkt vom USB. Nur die Leitung, über die der Rest der Schaltung versorgt werden soll, wird über den FET geschaltet. Dort ist aber auch noch nichts angeschlossen. EDIT: hab gerade einen 10k Pullup an Pin für den FET ergänzt, hat nichts geändert. Allerdings habe ich bei der Einstellung auch #SLEEP und #PWREN verwechselt. Aber eigentlich dürfte das doch an der Erkennung des Chips selbst nicht ändern...
Wenn wir mal davon ausgehen, dass das EEPROM intakt ist und der Chip sonst keinen Schaden genommen hat: Leg mal DSR# auf Masse. Und dann schau mal in das System-Log was beim Einstecken passiert, unter Linux in /var/log/messages und unter Win hoffentlich im Ereignis-Log. Wenn erst gar kein device erkannt wird (sich also tatsaechlich garnichts tut), ist entweder das EEPROM im Eimer oder der Chip ist defekt. Vielleicht kann er auch nur keinen Treiber zuordnen weil Du die Kennung geaendert hast, dann besteht noch Hoffnung, ihn zu retten. Fehler in der Schaltung (z.B. Kurzschluss oder Ueberlast) sollten zumindest mit einer entsprechenden Meldung enden. Ein Bild von Deinem tatsaechlichen Aufbau kann auch weiter helfen, am Schaltplan sehe ich nur, dass DSR# in der Luft haengt. Ansonsten ist es vom Schaltplan soweit OK. Selbst wenn der MOSFET-Teil nicht 100% ist (weiss nicht ob sich der verwendete eignet) sollte zumindest das Device erkannt werden, denn das ist ja durch den Bus stets mit Spannung versorgt. Ich hab zu Beginn meiner Experimente ein paar FT232 kaputt geflasht das lag aber auch daran, dass das verwendete Tool echt scheisse war oO"
Es wird schon bemerkt, dass da ein Gerät angeschlossen wurde. Es wird dann im Gerätemanager als "unbekanntes Gerät" gemeldet. DSR an Masse hat auch nicht geholfen... Nen Bild kann ich erst heute Abend liefern. Das Layout hab ich gerade nur als Eagle-Datei anzubieten, hab hier gerade leider kein Eagle installiert, sonst würde ich nen PDF davon machen. Das liefere ich dann auch nach...
Also wenn dann PNG. Mit dem Board-File kann ich hier nichts anfangen. Dann ist denke ich mal das EEPROM-Image, das Du gebrannt hast, korrupt. Die Botschaft ist wohl, doch weiterhin MPROG zu verwenden. Das Problem ist nun folgendes: Die VID/PID muss wieder korrekt geschrieben werden, sonst wird das device nicht mehr erkannt und auch kein passender Treiber geladen. Die Tools von FTDI werden auch nur auf diese IDs triggern. Eine Beschaedigung ist allerdings auch nicht ganz auszuschliessen. Ich wuerde wahrscheinlich einfach einen neuen Chip nehmen und dieses mal besser aufpassen. Ansonsten muesstest Du ja deren Tools umschreiben oder die Moeglichkeit haben, das device selber auszuwaehlen, das er verwenden soll. Michael
Also MProg erkennt auch verflashte Chips und kann die neu beschreiben. Aber nur, wenn sie sich überhaupt anmelden. VID/PID 0000 ist aber meist irgend ein anderer Fehler, da erkennt der Hostcxontroller vermutlich nur den PullUp Widerstand der ansagt, dass überhaupt ein Device da ist.... Kommen denn noch die 3,3V aus dem 3V3OUT Pin?
Ich habe gerade rausgefunden, dass man Eagle ohne Admin-Rechte installieren kann. Daher hier das Layout als PDF. DIe VID/PID habe ich nicht geändert, weil mir schon klar war, dass der Chip dann nicht mher richtig erkannt werden würde. Ich habe nur die Descriptor-Strings geändert. Und selbst wenn, müsste am PC dann doch die geänderte VID/PID angezeigt werden, es würde bloß der Treiber nicht gefunden werden. Es wird aber VID/PID = 0000 angezeigt, woraus ich schließe, dass das Gerät überhaupt nicht erkannt wurde, und nicht nur nicht identifiziert werden konnte.
Ich seh da ueberhaupt keine Verbindung von Masse und Spannungsversorgung der USB-Buchse. Was ist das ueberhaupt fuer eine komische Buchse mit nur zwei Pins? Wo ist die zweite Seite von dem Layout? Und haeng das doch mal als PNG an, dann kann man es sich im Browser auch ansehen.
Angehängte Dateien:
-
usb.png
23 KB
Das Layout ist nur einseitig. DIe USB-Buchse ist in SMD, die vier Signal-Pads habe ich jetzt mal beschriftet. Die großen, eckigen Pads an der Seite sind nur die Schirmung und die mechanische Befestigung.
OK jetzt komm ich mit... hab mich bissel verguckt. Naja wenn das mit dem Schaltplan uebereinstimmt, den Du gepostet hast, sollte die Schaltung nicht das Problem sein (so lange kein Problem mit dem Aufbau vorliegt).
Sag mal kann es sein dass Du den MOSFET falsch rum in der Schaltung hast?
Habe jetzt dem MOSFET mal abgetrennt, das bringt aber auch nichts. Ich denke, ich werde gleich nen neuen Chip versuchen...
uwegw schrieb: > Das Layout ist nur einseitig. > DIe USB-Buchse ist in SMD, die vier Signal-Pads habe ich jetzt mal > beschriftet. Die großen, eckigen Pads an der Seite sind nur die > Schirmung und die mechanische Befestigung. Sicher das die USB-Buchse so belegt ist? Mir ist keine Buchse mit dieser Belegung bekannt. USB-A/B ist (von den Anschlüssen auf der Platine gesehen, von links nach rechts) immer GND, D+, D-, VBUS. Mini-USB ist GND, ID, D+, D-, VBUS
Arc Net schrieb: > Sicher das die USB-Buchse so belegt ist? > Mir ist keine Buchse mit dieser Belegung bekannt. > USB-A/B ist (von den Anschlüssen auf der Platine gesehen, von links nach > rechts) immer GND, D+, D-, VBUS. > Mini-USB ist GND, ID, D+, D-, VBUS Da hat er recht, hab gerade nochmal bei meinen FTDI-Aufbauten geschaut, VCC und GND sind jeweils außen. Toby
Er meinte ja dass er den IC ein mal programmieren konnte, daher muss die Buchse zwangslaeufig richtig belegt sein. Ich vermute eher dass das geschriebene EEPROM-Image fehlerhaft war... oder der falsch eingebaute MOSFET hat irgendetwas geliefert, nachdem CBUS0 auf #SLEEP gesetzt wurde.
ach ja ich nehm MPrpg zum beschreiben? was ist denn FT_prog?
FT_Prog ist das Nachfolgeprogramm von MProg. Die Belegung der USB-Buchse würde ich als Fehlerquelle definitv ausschließen, da ich den Chip ja vor der missratenen Programmerung schon mal erfolgreich betrieben habe...
uwegw schrieb: > FT_Prog ist das Nachfolgeprogramm von MProg. > > Die Belegung der USB-Buchse würde ich als Fehlerquelle definitv > ausschließen, da ich den Chip ja vor der missratenen Programmerung schon > mal erfolgreich betrieben habe... Aber seltsam ist es schon... Du hast nicht zufällig noch ein anderes Gerät am PC, wo evtl. ein FTDI-Chip drin sein könnte, und aus versehen das beschrieben?
So ein Mist... habe jetzt nen neuen FT232 draufgelötet. Der wurde erst wieder sofort erkannt, die Datenübertragung lief auch prima. Dann habe ich diesmal nur CBUS3 auf RX&TXLED umgestellt, und beim nächsten Einstecken war das Teil wieder tot. Das könnte meiner Meinung nach eigentlich nur noch am Rechner und der Software liegen... Beim nächsten Mal probiere ich mal nen anderen PC. Ich hab noch einen FT232 hier, der allerdings schon mal falschrum eingelötet, dannn ausgelötet und sicherheitshalber nicht mehr verwendet wurde. Den teste ich jetzt mal, aber vielleicht ist der auch schon überhitzt gewesen...
Benutz mal lieber MProg oO (das alte Tool).
Na ja, immerhin lebt der letzte FT232 noch, und beim zweiten Umlöten ist die Anzahl der Pads auf der Platine soagr konstant geblieben. Ich hätte das Teil ohne Not nicht mehr verwendet, weil ich ihn vor Jahren mal verkehrum gelötet, das sofort gemerkt und ihn dann mit dem Bügeleisen ausgelötet habe... Ich werde jetzt wohl erst mal auf Bus-Power für mein Gerät verzichten (dafür hätte ich nen CBUS-Pin auf PWREN umstellen müssen), bei Gelegenheit neue FT232 bestellen und mal an nem anderen Rechner die Programmierung versuchen... Trotzdem erst mal Danke an alle, die versucht haben zu helfen! mfg Uwe
Hallo, FT_PROG 1.3.1 benutze ich derzeit, um einen FT4232H zu programmieren. Hier scheint sich gerade zu ergeben, dass FT_PROG einzelne Bits einfach falsch benennt: Der Chip hat vier Ports A,B,C,D. Fürjeden Port kann man ein Bit brennen, das vorgibt, ob der VCP-Driver (Virtual COM-Port-Treiber) geladen wird. Das sieht man dann im Geräte-Manager. In FT_PROG kann man die vier Kanäle justieren, brenn und wieder einlesen. Nur sind halt hier die Kanäle B und C vertauscht. Mit M_PROG kann man die kanäle entsprechend mit dem Geräte-Manager übereinstimmend einstellen. Eine Anfrage bei FTDI läuft gerade.Das Ergebnis werde ich hier noch posten. Angeblich gibt es dann eine neue Version von FT_PROG mit einer Korrektur. Das Ganze hier nur, um das Vertrauen in FT_PROG etwas zu schwächen und mit zB. M_PROG oder anderm Utility zu überprüfen. Grüße, BMO
So, nachdem ich mal wieder neue FT232 bestellt habe, hab ich vor ein paar Tagen den nächsten Versuch gewagt. Neue Platine gelötet, mit den Standardeinstellungen läuft alles einwandfrei. Also der nächste Programmierversuch, diesmal an einem anderen PC, aber dieselbe FT_PROg-Version (v1.2.4). Einstellungen gemacht, geflasht, Gerät neu angesteckt, tot! Allerdings kam vor dem Flashen die Warnung , dass auf externen Takt ungestellt würde! Ich hab dann auf Abbrechen geklickt, die Einstellungen nochmal überprüft, und es stand definitv auf internem Takt. Dann endgültig geflahst, die Meldung kam nicht wieder, und weg war er. Daher fiel mein Verdacht jetzt erstmals auf ein Problem mit dem Takt (vorher habe ich gar nicht gewusst, dass man den FT232 auch extern takten kann). Also habe ich jetzt einen externen 12MHZ Oszillator angeschlossen, und siehe da: ER LEBT! Meldet sich beim PC, als wenn nichts gewesen wäre... EDIT: mit FT_PROG V1.3.1 hab ich dann den nächsten Versuch gemacht. Die Taktquelle ließ sich wieder auf den internen Oszillator setzen, und die anderen Einstellungen waren schon beim ersten Versuch erfolgreich.
Kann es sein das wie es BMO schon schrieb, dein FT-Prog einen Bug hat! Ich habe mit M-Prog mehrere FT232 RL einwandfrei programmiert und die Schaltung nach Bild 7.3 verwendet. Keine Probleme! Grüße Jürgen
Davon gehe ich mittelweile auch aus, zumal es mit FT_PROG V1.3.1 jetzt auch mit einem weiteren FT232 sofort funktioniert hat. MPROG hab ich auch schon mal runtergeladen, mit externem Takt wurde der Chip auch erkannt, aber ich fand nirgendwo die Option zum Unstellen der Taktquelle. Daher hab ich dann FT_Prog V1.3.1 genommen.
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.