Hallo, ich habe eine eigene Schaltung mit einem USB-Hub von TI und einem FT232H von FTDI (siehe Schaltplan). Jetzt habe ich das Problem, dass ein Gerät im Gerätemanager als "unknown device" angezeigt wird (ich gehe davon aus, dass es der FT232H ist). Der FT232R und der USB-Hub werden problemlos erkannt. Auch im FTProg von FTDI erscheint nur der FT232R und nicht der FT232H. Hat jemand eine Idee woran das liegen könnte? Danke für die Hilfe!
Gast
#4057183
Am HUB. Schon mal ohne HUB probiert?
Gast
#4057295
Was wird im Gerätemanager unter Details bei HW IDs angzeigt? Wenn VID und PID beide 0000 oder FFFF sind, liegt ein elektrisches Problem vor. Immerhin muss der FT232H in Highspeed laufen, dem FT232R reicht Fullspeed. Aber earum Überhaupt der Aufwand mit dem Hub und nicht statt dessen einen FT2232H?
Hallo, danke für die Antworten. Das mit dem Hub überbrücken teste ich morgen mal...ist mir nicht eingefallen :D IDs werden keine angezeigt. Der FT232H sollte in der Schaltung verwendet werden (ich weiß das Auswahlkriterium jetzt leider nicht mehr). Ich teste morgen mal das überbrücken des Hubs. Wenn der Chip dann erkannt wird habe ich einen neuen Suchansatz.
Gast
#4057343
Daniel K. schrieb: > IDs werden keine angezeigt. IDs werden immer angzeigt, Im Geräte Manager auf Eigenschaften des unbekannten Geräts, und dann auf Details.
Lattice User schrieb: > Daniel K. schrieb: > >> IDs werden keine angezeigt. > > IDs werden immer angzeigt, > Im Geräte Manager auf Eigenschaften des unbekannten Geräts, und dann auf > Details. Sorry, ich meinte es werden als ID "0000" angezeigt
So ich habe den Hub mal überbrückt...es wird aber weiterhin "unknown Device" angezeigt (siehe Screenshot).
Angehängte Dateien:
-
Unbenannt.png
(75 KB)
Gast
#4057989
china fake Teil?
Von den Chips habe ich das zwar noch nicht gelesen, aber das klingt verdächtig nach: http://www.heise.de/make/meldung/FTDI-Proaktive-Fake-Chip-Abwehr-2430780.html
Hallo, mmh den Chip hat ein Bestücker bei Farnell bestellt... An der Beschaltung etc. kann es aber nicht liegen das er sich so verhält?
Daniel K. schrieb: > An der Beschaltung etc. kann es aber nicht liegen das er sich so > verhält? Natürlich kann das der Fall sein. Da genügt ein einzelner Pullup-Widerstand an einer der USB-Datenleitungen, und das geschilderte Verhalten tritt ein. Du wirst Dir also Deine Beschaltung genau ansehen müssen. Poste Deinen Schaltplan und gegebenenfalls ein Bild vom Aufbau.
Rufus Τ. Firefly schrieb: > Daniel K. schrieb: >> An der Beschaltung etc. kann es aber nicht liegen das er sich so >> verhält? > > Natürlich kann das der Fall sein. Da genügt ein einzelner > Pullup-Widerstand an einer der USB-Datenleitungen, und das geschilderte > Verhalten tritt ein. > > Du wirst Dir also Deine Beschaltung genau ansehen müssen. > > Poste Deinen Schaltplan und gegebenenfalls ein Bild vom Aufbau. Hallo Rufus, den Schaltplan habe ich im ersten Post schon hochgeladen gehabt und nach diesem Schaltplan wurde das Layout erstellt. Der einzige Unterschied ist nur, dass die Pull-Down Widerstände für DP2 (sprich dem USB vom FT232H) fehlen (nicht bestückt) und das ich die Widerstände in der Datenleitung 2 vom Hub (die 27 Ohm) entfernt habe und eine Verbindung zwischen dem USB vom FT232H zum Pin 9 und 10 vom Steckverbinder "IO" hergestellt habe um den FT232H direkt mit dem PC verbinden zu können (also komplett ohne Hub dazwischen). Ein fehlender Pull-Up ist nicht vorhanden. Ich habe auf der USB D+ Leitung vom Hub zum FT232H 3,3V anliegen.
Oh. Nun, Dir wird nichts anderes übrig bleiben, als die Funktion einzeln zu testen. Schnapp Dir ein Oszilloskop und prüfe die Spannungen an den verschiedenen Versorgungsspannungsanschlüssen, prüfe, ob der Oszillator schwingt ... und vergleiche Deine Beschaltung nochmal genau mit der im Datenblatt angegebenen.
Gast
#4058261
Tja, mit Pull-up an EEDATA sollte es klappen! ;) Gruß Jochen
Hallo, der Pull-Up an EDATA hat das Problem gelöst. Der Chip wird nun gefunden und ich kann ihn beschreiben.
Daniel K. schrieb: > Hallo, > > der Pull-Up an EDATA hat das Problem gelöst. Der Chip wird nun gefunden > und ich kann ihn beschreiben. Jetzt hat sich aber ein neues Problem gezeigt (siehe Screenshot). VID und PID kann ich aber dieses mal auslesen und er meldet das der USB-Hub Stromverbrauch überschritten wurde.
Angehängte Dateien:
-
Unbenannt.png
(78 KB)
Gast
#4058715
> und er meldet das der USB-Hub Stromverbrauch überschritten wurde
Tja dann wurde wohl der erlaubte Strom überschritten =;)
Aber das enumeriern hat geklappt. Was steht denn im EEPROM für ein
erlaubter Strom. Und was kann das HUB liefern das den Fehler gemeldet
hat.
Wieviel zieht denn deine Schaltung?
Hallo, das merkwürdige ist ja, dass ich die Schaltung nicht per USB betreibe sondern mit einem 12V Netzteil. Der Betrieb über die USB-Spannung ist nicht vorgesehen. Das Netzteil zeigt einen Strom von ~100mA an. Die Überstrom-Fehlermeldung taucht auch nicht mehr auf, wenn ich den FT232H vom Hub trenne, sprich wenn ich die 27R Widerstände aus den Datenleitungen entferne. Ich habe auch die Vermutung, dass ich wegen dieser Fehlermeldung nicht mittels FTProg auf den Chip komme (siehe Screenshot). Der FT232R wird von FTProg erkannt.
Angehängte Dateien:
-
Unbenannt.png
(42 KB)
Daniel K. schrieb: > das merkwürdige ist ja, dass ich die Schaltung nicht per USB betreibe > sondern mit einem 12V Netzteil. Das ist egal - der USB-Stack wertet aus, was die Geräte anmelden, gemessen wird nirgends. Und wenn Dein HUB meint, ein Hub ohne Netzteil (bus-powered) zu sein, dann darf an jedem Port nicht mehr als 100 mA angemeldet werden.
Rufus Τ. Firefly schrieb: > Daniel K. schrieb: >> das merkwürdige ist ja, dass ich die Schaltung nicht per USB betreibe >> sondern mit einem 12V Netzteil. > > Das ist egal - der USB-Stack wertet aus, was die Geräte anmelden, > gemessen wird nirgends. > > Und wenn Dein HUB meint, ein Hub ohne Netzteil (bus-powered) zu sein, > dann darf an jedem Port nicht mehr als 100 mA angemeldet werden. Hallo, danke für die Info. Das war mir so nicht bewusst. Ich werde es morgen früh direkt mal ausprobieren und Feedback geben :)
Gast
#4059064
Daniel K. schrieb: >> >> Und wenn Dein HUB meint, ein Hub ohne Netzteil (bus-powered) zu sein, >> dann darf an jedem Port nicht mehr als 100 mA angemeldet werden. > > Hallo, > > danke für die Info. Das war mir so nicht bewusst. Ich werde es morgen > früh direkt mal ausprobieren und Feedback geben :) Wenn der Schaltplan stimmt, ist das korrekt konfiguriert. (Pin 8 = /BUSPWR am TUSB2036 ist high). Was mir auffällt: 1.) NP3 ist auf Low, d.h. der TUSB2036 ist als 3 Port Hub konfiguriert, der dritte Port ist aber offen. Eventuell macht das Ärger. 2.) Der FT232H ist ein Highspeed Device, der TUSB2036 aber nur ein Fullspeed Hub.
Lattice User schrieb: > Daniel K. schrieb: > >>> >>> Und wenn Dein HUB meint, ein Hub ohne Netzteil (bus-powered) zu sein, >>> dann darf an jedem Port nicht mehr als 100 mA angemeldet werden. >> >> Hallo, >> >> danke für die Info. Das war mir so nicht bewusst. Ich werde es morgen >> früh direkt mal ausprobieren und Feedback geben :) > > Wenn der Schaltplan stimmt, ist das korrekt konfiguriert. (Pin 8 = > /BUSPWR am TUSB2036 ist high). > > Was mir auffällt: > 1.) NP3 ist auf Low, d.h. der TUSB2036 ist als 3 Port Hub konfiguriert, > der dritte Port ist aber offen. Eventuell macht das Ärger. > > 2.) Der FT232H ist ein Highspeed Device, der TUSB2036 aber nur ein > Fullspeed Hub. In der ersten Schaltung ist der Hub noch als Buspowered konfiguriert...das war eine der ersten Änderungen. Daher habe ich da nicht mehr dran gedacht. Die Änderung mit Selfpowered habe ich nachträglich gemacht. Daher kann das das Problem schon erklären. Mit Hilfe der NP 0 und 1 Pins sage ich dem Hub, dass zwei Geräte permanent angeschlossen sind und das dritte extern verfügbar ist. Daher glaube ich nicht, dass die Beschaltung das Problem verursacht.
Gast
#4059122
Daniel K. schrieb: > > Mit Hilfe der NP 0 und 1 Pins sage ich dem Hub, dass zwei Geräte > permanent angeschlossen sind und das dritte extern verfügbar ist. Daher > glaube ich nicht, dass die Beschaltung das Problem verursacht. wenn ich das Datenblatt richtig verstehe, hat das nur Auswirkungen auf den HUB Descriptor, d.h. dem Host wird mitgeteilt, dass die an den Ports 1+2 angeschlossenen Geräte nicht einzelen entfernt werden können. Der offene dritte Port ist in jedem Fall nicht korrekt, denn für sauberes Hotplug müssen die DP/DN mit 15k auf Low gezogen werden. Bei Offen besteht die Gefahr das die kleinsten Störungeung ein falsches Hotplug Event auslösen. Auch wenn es nichts mit dem aktuellen Problem zu tun hat, sollte man es korrigieren.
Lattice User schrieb: > Daniel K. schrieb: >> >> Mit Hilfe der NP 0 und 1 Pins sage ich dem Hub, dass zwei Geräte >> permanent angeschlossen sind und das dritte extern verfügbar ist. Daher >> glaube ich nicht, dass die Beschaltung das Problem verursacht. > > wenn ich das Datenblatt richtig verstehe, hat das nur Auswirkungen auf > den HUB Descriptor, d.h. dem Host wird mitgeteilt, dass die an den Ports > 1+2 angeschlossenen Geräte nicht einzelen entfernt werden können. > > Der offene dritte Port ist in jedem Fall nicht korrekt, denn für > sauberes Hotplug müssen die DP/DN mit 15k auf Low gezogen werden. Bei > Offen besteht die Gefahr das die kleinsten Störungeung ein falsches > Hotplug Event auslösen. Auch wenn es nichts mit dem aktuellen Problem zu > tun hat, sollte man es korrigieren. Gut. Danke für den Hinweis. Ich werde es einbauen.
Daniel K. schrieb: > Lattice User schrieb: >> Daniel K. schrieb: >>> >>> Mit Hilfe der NP 0 und 1 Pins sage ich dem Hub, dass zwei Geräte >>> permanent angeschlossen sind und das dritte extern verfügbar ist. Daher >>> glaube ich nicht, dass die Beschaltung das Problem verursacht. >> >> wenn ich das Datenblatt richtig verstehe, hat das nur Auswirkungen auf >> den HUB Descriptor, d.h. dem Host wird mitgeteilt, dass die an den Ports >> 1+2 angeschlossenen Geräte nicht einzelen entfernt werden können. >> >> Der offene dritte Port ist in jedem Fall nicht korrekt, denn für >> sauberes Hotplug müssen die DP/DN mit 15k auf Low gezogen werden. Bei >> Offen besteht die Gefahr das die kleinsten Störungeung ein falsches >> Hotplug Event auslösen. Auch wenn es nichts mit dem aktuellen Problem zu >> tun hat, sollte man es korrigieren. > > Gut. Danke für den Hinweis. Ich werde es einbauen. Hab den BUSPWR Pin auf High gezogen....der Fehler ist weg. Danke für die Hilfe :) Es läuft nun wunderbar.