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 VDDCORE
korrekt 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?
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:
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.
EEDATA/GANGED
an 3,3 V gebunden) und die nicht verwendeten Überstromeingänge nicht angeschlossen sind, was dazu führt, dass alle nachgeschalteten USB-Ports deaktiviert werden.
Ale..chenski
Tom