LAN9500A Ethernet-Adapter

Ich entwerfe einen USB-zu-Ethernet-Adapter (eigentlich ein Prototyp eines Stücks einer größeren Platine). Wie diejenigen, die meinen Fragen folgen, wissen werden, hatte ich einige Höhen und Tiefen, um den USB-Teil zum Laufen zu bringen, aber jetzt wird er als USB-Hub in Linux angezeigt und ich kann daran angeschlossene Geräte verwenden. Nun zum Ethernet-Teil.

Soweit ich das beurteilen kann, habe ich die verschiedenen Hinweise im Datenblatt befolgt. Das Schema ist unten gezeigt. Ich kann bestätigen, dass dies VDDCOREkorrekt generiert wird und dass auf dem 25-MHz-Quarz eine 25-MHz-Sinuswelle vorhanden ist - der Chip zeigt also einige Lebenszeichen. Aber es zeigt sich nicht in einem Scan des USB-Busses. Beide Jumper (JX1 und JX2) sind installiert, obwohl ich es auch ohne versucht habe.

Was kann ich tun, um zu versuchen, dies zu debuggen? Worauf muss ich bei der Platine achten? Habe ich offensichtliche Fehler gemacht?

Geben Sie hier die Bildbeschreibung ein

Aus Ihren vorherigen Anfragen verbinden Sie all dies mit Raspberry Pi. Rpi verfügt über einen USB 2.0 HS-Host in voller Größe mit 480 Mbit / s. Warum lähmen Sie Ihr Design auf 12 MBit/s?
Weil ich nichts besseres brauche.

Antworten (1)

Der Hauptfehler in Ihren Schaltplänen besteht darin, dass das nRESET-Signal (Pin 24) nicht den Verzögerungsspezifikationen folgt. Die Deaktivierung dieses Signals muss verzögert werden, bis alle Versorgungsspannungen einen gültigen Pegel erreichen:

Geben Sie hier die Bildbeschreibung ein

In Ihren Schaltplänen ist der nRESET direkt an die Stromschiene gebunden, was offensichtlich gegen die Spezifikationen verstößt. Wenn der LAN7500 IC keinen "gültigen Reset" empfangen kann, ist er intern verschraubt und funktioniert nicht.

Um dieses Signal richtig zu handhaben, wird dringend empfohlen, einen "Spannungsüberwachungs"-IC wie MAX809 zu verwenden. Diese Methode bietet ein garantiertes Zurücksetzen unter verschiedenen Einschalt- und Brownout-Bedingungen. Im einfachsten/günstigsten Fall können Sie an diesem Pin eine RC-Verzögerung verwenden, dies ist jedoch in instabilen Einschaltsituationen ein Glücksspiel.

ADDITION: Ein weiteres typisches Problem mit eingebetteten Hubs und eingebetteten Geräten ist die Sequenzierung von VBUS_DET auf der LAN9500-Seite. Um eine Verbindung zum Hub herzustellen, muss das LAN9500 ​​D+ hochziehen, wenn es VBUS_DET sieht, und nicht vorher. Sie sollten Oszilloskopspuren darüber erhalten, was auf den D+/D-Drähten zwischen dem Hub und dem LAN vor sich geht. Theoretisch sollte das Verbindungsereignis NICHT auftreten, bevor der Hub betriebsbereit ist (aufgezählt werden und so). Wenn das Verbindungsereignis (D+ pull HIGH) davor auftritt, könnte die Statusmeldung des Hubs vermasselt sein. Um zu testen, ob dies das Problem ist, schalten Sie VBUS_DET vorübergehend auf Masse und prüfen Sie, ob der Hub/Host beginnt, das Verbindungsereignis zu erkennen und etwas zu tun (USB_RESET usw. usw.).

Um die Verbindung korrekt herzustellen und eine ordnungsgemäße Sequenzierung unabhängig von Leistungsrampenraten zu erhalten, ist es ratsam, den VBUS_DET mit der richtigen Polarität an den Leistungssteuerstift auf der Nabenseite, PWRON1, anzuschließen. Der PWRON1-Pin ist logisch inaktiv, bis der Hub vollständig aufgezählt und betriebsbereit ist, wodurch sichergestellt wird, dass LAN9500 ​​den Verbindungsprozess startet, nachdem alles bereit ist.

Bitte sehen Sie sich das Referenzdesign genauer an, ww1.microchip.com/downloads/en/DeviceDoc/…
Danke. Laut Datenblatt kann ich dies einfach unverbunden lassen (was ich in einer früheren Überarbeitung getan habe - dachte, ich hätte das Richtige getan, um es mit +3.3 zu verbinden!)
@Tom, in der LAN7500-Spezifikation gibt es keine so dumme Sache, sie unverbunden zu lassen. Die Spezifikation sagt: "Die Bestätigung von nRESET ist nach dem Einschalten erforderlich." - Tabelle 2-6, ww1.microchip.com/downloads/en/DeviceDoc/00001734A.pdf
Aber das ist kein LAN7500, es ist das LAN9500A. Im Abschnitt 5.13.2 des Datenblatts heißt es: „Der nRESET-Pin wird intern vom Gerät hochgezogen und kann bei Nichtverwendung unverbunden bleiben. ww1.microchip.com/downloads/en/DeviceDoc/00001875C.pdf
Aber dann hat das Referenzdesign nur nRESET an 3,3 V gebunden - ww1.microchip.com/downloads/en/DeviceDoc/9500a_sch.pdf
@ Tom, Entschuldigung, ich habe das falsche Dokument gelesen und mich auf es bezogen. Der Rat, nRESET richtig umzuschalten, bleibt bestehen, unabhängig davon, ob der IC über einen eingebauten POR verfügt. Siehe auch eine Ergänzung.
Ich habe die Verbindung von VBUS_DET auf 3,3 V in einen Pull-up auf 3,3 V über 12 k geändert und dann versucht, VBUS_DET vorübergehend zu erden. USBDP bleibt auf seinem Ruhepegel (ca. 600 mV) - beachten Sie, dass ich den Jumper JX1 entfernt habe. Wenn JX1 installiert ist, wird D + nach dem Einschalten für einige Zeit auf Masse gezogen, ich nehme an, vom Hub als Teil des USB-RESET. Aber der LAN9500A reagiert darauf nicht.
Das LAN9500A-Datenblatt sagt nichts darüber aus, ob es einen externen Pull-up auf D + benötigt, aber ich nehme an, dass USB 2.0-Geräte es intern haben müssen, damit es getrennt werden kann?
@ Tom, der LAN9500A sollte D + Pull-up in USB 2.0 PHY integriert haben. Irgendetwas stimmt mit Ihrem Design nicht, 600 mV Leerlauf sind falsch. Sie haben die Hauptmasse (untere Schnecke nicht gelötet) oder so etwas fehlt. Holen Sie sich einen LAN9500A-Evaluierungs-Dongle und vergleichen Sie Signale/Layout, element14.com/community/docs/DOC-70322/l/…
Nun, der Hinweis auf einen nicht gelöteten Bottom Slug hat mich dorthin gebracht. Nicht abgelötet; Der Footprint, den ich für den LAN9500A verwendet habe, hat den Slug als NC. Das Verbinden mit Masse (glücklicherweise ziemlich einfach, da es unbedeckte Durchkontaktierungen darin gibt) löste einige der Probleme; USBD+ läuft jetzt im Leerlauf bei etwa 3,3 V. Immer noch keine USB-Kommunikation, aber ich denke, das liegt daran, dass sich der TUSB2046B im Ganged-Power-Modus befindet ( EEDATA/GANGEDan 3,3 V gebunden) und die nicht verwendeten Überstromeingänge nicht angeschlossen sind, was dazu führt, dass alle nachgeschalteten USB-Ports deaktiviert werden.
Nochmals vielen Dank für Ihre Geduld und Hilfsbereitschaft; Ich lerne viel, vor allem über den Wert, jemanden zu haben, der qualifiziert ist, Designs zu überprüfen!