Was ist die Quelle dieser Form in meinem USB-Augendiagramm?

Ich habe ein USB-Gerät um einen STM32F105 herum entworfen . Es handelt sich um ein USB 2.0 Full Speed ​​CDC-Gerät, das als virtueller COM-Port unter Verwendung der USB-Bibliothek von ST konfiguriert ist . Es verwendet die eingebaute PHY des STM32 und läuft mit 12 Mbps.

Ich sende Daten in 254-Byte-Paketen. Gelegentlich (durchschnittlich 1 von 17000 Paketen) empfängt der Host-Computer fehlerhafte Daten. Es ist im Allgemeinen auf ein einzelnes Byte im Paket beschränkt.

Also betrachte ich die Signale mit einem Tektronix TDS2025 O-Scope (200 MHz).

Die meisten Übergänge sehen gut aus:

USB1

Aber mein Low-Tech-Augendiagramm zeigt etwas Unerwartetes:

Auge

Ich habe es geschafft, eine der schlechten Wellenformen einzufangen, die so aussieht:

USB2

Was könnte dies verursachen? Ich bin mir nicht sicher, wo ich anfangen soll zu suchen.

Wenn ich das Gerät zum ersten Mal einstecke, findet die Aufzählung erfolgreich statt und das Augendiagramm sieht sauber aus. Aber sobald ich den COM-Port öffne (mit PuTTY, Hercules oder meiner benutzerdefinierten Java-Software), werden die Störungen angezeigt. Ich verwende ein Lenovo Thinkpad mit Windows 7.

Hier ein Bild vom Layout:

Leiterplatte

Der TVS IC ist ein NXP PRTR5V0U2F und der Ladedetektor ist ein TI BQ24392 .

Die USB-Spuren bewegen sich etwa einen Zoll auf der Rückseite der Platine, dann kommen sie wieder hoch und verbinden sich direkt mit den USB-Pins des Mikrocontrollers. Sie sind impedanzgesteuert und in geeigneter Länge aufeinander abgestimmt.

Ich prüfe von den Lötpads des USB-Anschlusses zum Massepunkt, den ich auf dem Bild beschriftet habe. Die Sonde hatte eine kurze Erdungsfeder, keine lange Krokodilklemme.

Wenn mehr Daten helfen würden, lassen Sie es mich bitte wissen. Außerdem ist dies mein erstes USB-Gerät und mein erster Sehtest. Wenn Sie feststellen, dass etwas mit meinem Setup oder meinen Annahmen nicht stimmt, lassen Sie es mich bitte wissen.

2,2R als Vorwiderstand für Ihre Datenleitungen erscheinen mir ziemlich niedrig. Können Sie bestätigen, dass es 2.2R und nicht 22R ist, wie ich es erwarten würde? Haben Sie ein Referenzdesign, aus dem Sie das entnommen haben? Können Sie auch bestätigen, dass Sie zumindest versucht haben, die USB-Signalleitungen mit der gleichen Länge und ungefähr 50 Ohm zu verlegen?
Es ist unwahrscheinlich, dass das TVS oder der Ladedetektor das Signal so stören. Ich habe jedoch keine Ahnung, warum der STM32 dieses Verhalten zeigen würde.
Das sieht nach einer Reflexion aus, müsste aber an einem ziemlich langen Kabel liegen. Vielleicht eine Art Streit? Ich denke, meine erste Debugging-Aktion wäre, den Ladedetektor zu entlöten und mit ein paar Drähten zu überbrücken.
Ich würde das Problem woanders suchen. Dieses Signal sieht aus wie ein Übergang von Fahren (1 oder 0) zu High-Z.
@TomL., ja, sie sind 2.2R. Das kam von einem funktionierenden Entwicklungsboard, das von einem HF-Transceiver-Hersteller bereitgestellt wurde und denselben Mikrocontroller verwendet, aber ich habe die Signalisierung des Entwicklungsboards nie wirklich qualifiziert ... Es hört sich so an, als sollte ich 22R verwenden :) Ja, die Spuren wurden auch für 90- modelliert Ohm-Differential und wurden nahezu auf der gleichen Länge gehalten. Sie sind jeweils etwa einen Zoll lang. Sie wechseln von der oberen zur unteren Schicht direkt am Ladedetektor, der Wechsel zurück direkt am Mikrocontroller.
Die Reflexion (wo auch immer sie sein mag) geht in eine niedrigere Impedanz (Reflexion ist phasenverschoben). Ich würde vorschlagen, dass die zwei unterschiedlich aussehenden Signale die zwei unterschiedlichen Signalisierungsrichtungen sind.
@GregoryKornblum Ich hatte den gleichen Gedanken. An den USB-Leitungen ist nichts anderes angeschlossen. Ich könnte versuchen, die neueren USB-Bibliotheken von ST zu verwenden; Vielleicht sind die, die ich verwende, fehlerhaft?
@ThePhoton. Danke schön. Ich werde zuerst die Reflexionstheorie überprüfen, weil ich die Widerstände leichter wechseln kann, als ich sie an diese winzigen kleinen Pads löten kann :)
Diese Widerstände sind wahrscheinlich der von der USB-Spezifikation geforderte Reihenabschluss. Laut Spezifikation sollten sie etwa 16R-33R betragen (2,2 ist definitiv zu klein), um die unterschiedliche Impedanz des USB-Kabels zu berücksichtigen. Dies kann zu Problemen führen, aber sie würden wahrscheinlich nicht so angezeigt werden, wie Sie es tatsächlich sehen (sie sollten konsistenter sein). Ich würde auf jeden Fall überlegen, sie zu wechseln.
Versuchen Sie, in der Mitte der Wellenform zu sampeln – das Augendiagramm sieht gut genug aus, um es richtig zu decodieren.
Kann jemand den Ursprung und die Bedeutung von "Augendiagramm" erklären?
Danke für den hervorragenden Link, @TomL. Darauf war ich noch nie gestoßen.

Antworten (3)

Es sieht nicht so aus, als ob es sich um ein Hardwareproblem handelt. Die gestufte Wellenform sieht entweder so aus, als würde eine Reflexion stattfinden, oder dies geschieht am Übergang, wenn der Host und das Gerät die Sender- und Empfängerrollen wechseln. In jedem Fall sieht das Signal gut genug aus, um richtig dekodiert zu werden.

Es würde helfen, wenn Sie den Auslöser Ihres Zielfernrohrs irgendwo auf dem Bildschirm platzieren. Wenn der Trigger außerhalb des Bildschirms liegt, kann es sein, dass Sie offensichtlicher Jitter bekommen, als es wirklich auf einem Bit ist.

Sie müssen sich Ihre Software genau ansehen. Höchstwahrscheinlich haben Sie irgendwo einen Fehler, der ein Byte beschädigt oder verfehlt oder hinzufügt, wenn ein bestimmter Eckfall auftritt. Dies könnte zum Beispiel während einer Konkurrenz um den FIFO sein, wenn es ein Byte zu wenig voll ist oder so. Wenn auf den FIFO sowohl von Interrupt- als auch Vordergrundcode zugegriffen wird, dann ist dies genau die Art von schwer zu findendem Problem, das Sie erwarten, wenn die Sperrlogik nicht ganz richtig ist.

Danke Olin. Es stellte sich heraus, dass es sich um einen Softwarefehler handelte. Die USB-Bibliothek von ST füllt die ausgehende Warteschlange Byte für Byte ( Buffer[index] = data; index++;). Als ich meine eigene Funktion gebaut habe, habe ich es so gemacht: Buffer[index++] = data;Anscheinend würde der USB-Prozess (sehr gelegentlich) stattfinden, nachdem der Index inkrementiert wurde, aber bevor die Daten geschrieben wurden.

Das ist ein absolut perfektes FS-Signal. Anscheinend prüft das OP die Signale am Geräteende des Kabels. Die FS-Signale werden per USB-Standard nicht abgeschlossen. Alle eingehenden Signale (hostgesteuert) sind in Ordnung, da sie am Zielpunkt gemessen werden. Wenn das Gerät jedoch gelegentlich ein Handshake-Paket (kurz ACK oder NAK oder anderes) zurücktreibt, trifft der Treiber auf die Übertragungsleitung. Ein Signal mit halber Amplitude (Shouder) wird entwickelt, bis die Reflexion vom Host-Ende zurückkommt. Dies ist ein absolut normales Verhalten von Signalen auf nicht abgeschlossenen Übertragungsleitungen. Wie ich sehe, beträgt die Roundtrip-Verzögerung etwa 20 ns oder 10 ns in eine Richtung. Dies zeigt, dass das verwendete Kabel etwa 2 m lang ist oder ein Standardkabel von 6 Fuß. Wenn das OP den Bus am Host-Ende untersuchen würde, würde er ein entgegengesetztes Bild sehen. Nur meine 2c.

Ausgezeichnet, Ali, danke! Das habe ich gesucht. Entschuldigung, dass ich bereits eine andere Antwort akzeptiert habe ...

Ich sende Daten in 254-Byte-Paketen. Gelegentlich (durchschnittlich 1 von 17000 Paketen) empfängt der Host-Computer fehlerhafte Daten. Es ist im Allgemeinen auf ein einzelnes Byte im Paket beschränkt.

Verwenden Sie einen FIFO? Wenn ja, überprüfen Sie Ihren Quellcode: Es gibt schlechte FIFO- Beispiele, die tatsächlich das Lesen eines "schlechten" Bytes ermöglichen.

Die „schlechte Wellenform“ liegt noch innerhalb der Spezifikation. Sie sehen wahrscheinlich eine Reflexion, wenn der PC Daten sendet. Dies ist besser, wenn Sie einen Hub oder die rückseitigen Anschlüsse eines Desktop-PCs verwenden, und schlechter bei Anschlüssen an der Vorderseite, die durch längere Kabel innerhalb eines PCs verbunden sind.

Was ist die Quelle dieser Form in meinem USB-Augendiagramm?
AntwortenHierDatenschutz-Bestimmungen1y, 0v