mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FT232RL nach Programmierung nicht mehr erkannt


Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
7.3. verwendet keinen FET. Meinst du 6.3?
Falls ja, hast du exakt die 6.3er Schaltung aufgebaut?

Ralf

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du ihn jetzt auch nicht mehr mit FT_Prog auslesen!? Vielleicht 
hast du ja auch versehentlich die Stromversorgung auf extern gestellt?

Autor: Uwe ... (uwegw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: uwegw (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: uwegw (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: uwegw (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sag mal kann es sein dass Du den MOSFET falsch rum in der Schaltung 
hast?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal aus dem Datenblatt...

Autor: uwegw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe jetzt dem MOSFET mal abgetrennt, das bringt aber auch nichts. Ich 
denke, ich werde gleich nen neuen Chip versuchen...

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias Plaputta (plaputta)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach ja ich nehm MPrpg zum beschreiben? was ist denn FT_prog?

Autor: uwegw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Tobias Plaputta (plaputta)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: uwegw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benutz mal lieber MProg oO (das alte Tool).

Autor: uwegw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: BMO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.