Ich versuche, eine Platine mit einem STM32F407- und LAN8720A-Ethernet-PHY aufzurufen, und ich kann anscheinend keine Ethernet-Frames empfangen - obwohl ich keine Probleme beim Übertragen von Frames habe.

Hardware-Setup

Ich habe einen 25-MHz-Quarz am STM32F4, der einen 25-MHz-Taktausgangspin in den LAN8720A treibt, der sich im REF_CLK_OUT-Modus befindet - und einen 50-MHz-Takt als Teil der RMII-Schnittstelle zum STM32F4 zurücktreibt.

Die Buchse / Magnete sind ein generisches Teil. Hier ist das Datenblatt:

Software

Ich verwende das neueste Update STM32CubeMX, um eine System Workbench für das STM32-Projekt zu generieren, die FreeRTOS, lwIP sowie die Peripherietreiber der ETH enthält. Ich habe keinen der generierten Codes wirklich berührt - daher wird der lwIP-Stack in einem FreeRTOS-Stack initialisiert.

Experimente

Wenn das lwIP meines Boards für eine statische IP 10.0.0.2 konfiguriert ist und ein USB-zu-Ethernet-Dongle auf meinem Computer für eine statische IP 10.0.0.1 konfiguriert ist, verbinde ich die beiden Geräte direkt mit einem Ethernet-Kabel, und mein Board versucht, eine Verbindung herzustellen zu einem Dienst an Port 80 des Computers. Ich nehme die Interaktion zwischen meinem Board und dem Computer mit Wireshark auf (läuft auf dem Computer und ist an den USB-zu-Ethernet-Konverter gebunden).

Aufgrund des Problems der nicht empfangenen Frames kommen wir nie an diesem ARP-Zeug vorbei: Wie Sie sehen können, kann der Stmicroe (mein Board) ARP-Pakete senden - von meinem Computer gehört - aber es scheint nie die Antwort von meinem Computer zu hören , da es immer wieder ARP-Pakete ausstößt.

Beide Geräte sind mit einer 255.255.255.0-Maske konfiguriert, und beide sind mit einer Gateway-Adresse von 10.0.0.1 (dem Computer) konfiguriert. Ich habe gehört, dass ARP-Tabellen durcheinander geraten und Computer ARP-Pakete ignorieren, aber ich kann mir nicht vorstellen, dass die Karte ARP-Pakete ignoriert, die von meinem Computer speziell an sie adressiert wurden - als Antwort auf die Anfragen, die die Karte ursprünglich gestellt hat.

Also tauche ich in die Datei ethernetif.c von lwIP ein und stelle fest, dass HAL_ETH_GetReceivedFrame_IT(&heth)ein Fehler zurückgegeben wird. Diese Funktion gibt einen Fehler zurück, weil (heth->RxDesc->Status & ETH_DMARXDESC_OWN)== 0 statt 1. Ich interpretiere das so, dass die DMA-Puffer derzeit für das MAC-Peripheriegerät aktiviert sind und noch nichts empfangen haben.

Außerdem habe ich überprüft, dass der HAL_ETH_IRQHandler niemals aufgerufen wird.

Ein Problem mit dem PHY?

Zu diesem Zeitpunkt vermutete ich, dass mein PHY selbst schuld war.

Um weitere Untersuchungen durchzuführen, habe ich meinen Saleae Logic Pro 16 an alle relevanten Signale angeschlossen und festgestellt, dass sowohl auf den TX0 / TX1- als auch auf den RX0 / RX1-Leitungen viel Verkehr herrscht. Hier ist eine Erfassung des Empfangsverkehrs mit dem 25-MHz-Eingangstakt:

RX_ERR ist die ganze Zeit niedrig, es sei denn, ich versuche, den 50-MHz-Taktausgang zu erfassen (was bei einem Gerät wie dem Saleae offensichtlich eine Herausforderung darstellt): In diesem Fall wird RX_ERR gelegentlich für einige Pakete hoch geblättert (was eigentlich ein gutes Zeichen ist - Der Stift scheint zu funktionieren.

Nächste Schritte

Ich habe versucht, ETH-Interrupts manuell zu aktivieren, indem ich aufgerufen habe, HAL_NVIC_EnableIRQ(ETH_IRQn);nachdem tcpip_init()in der MX_LWIP_Init()Task aufgerufen wurde , und das scheint das Problem nicht zu beheben. Ich bin mir nicht ganz sicher, ob die Ethernet-Interrupt-Routine überhaupt aufgerufen werden soll - das ist die Herausforderung bei der Einführung eines brandneuen Designs. Ich habe Probleme, das richtige Verhalten des Systems zu bestimmen, damit ich feststellen kann, wie sich mein Setup unterscheidet.

Während ich zuvor das STM32 / STM32CubeMX / FreeRTOS-Material verwendet habe, habe ich das Ethernet-Peripheriegerät des STM32 noch nie verwendet, und meine einzige Erfahrung mit diesem Material ist auf benutzerdefinierten eingebetteten Linux-Systemen, die immer sofort zu funktionieren schienen. Das ist Neuland für mich!

Ich bin mir sicher, dass es irgendwo ein dummes Kontrollkästchen oder eine magische Ethernet_EnableReceive()Funktion gibt, die ich vergessen habe aufzurufen, aber ich kann keine Dokumentation finden, die darauf hindeutet, dass dieses Zeug explizit aktiviert werden muss, und die Beiträge, die ich im Internet sehe, sind alle nicht verwandt Probleme.

Wenn jemand irgendwelche Ideen hat, würde ich mich über Hilfe freuen!

Nachtrag: FreeRTOS loswerden

Um Dinge zu eliminieren, habe ich die FreeRTOS-Projektkomponente entfernt und bin zu einem Bare-Metal-Projekt zurückgekehrt. In meiner Hauptschleife rufe ich an MX_LWIP_Process(). Diese Methode sollte die Notwendigkeit von Interrupts beseitigen, behebt das Problem jedoch nicht. Ich kann immer noch keine Frames empfangen. Dies lässt mich denken, dass der von STM32CubeMX generierte ETH HAL-Code etwas enthält.

Lösung

Nur für den Fall, dass jemand in Zukunft auf diese Frage stößt, stellte sich heraus, dass das Problem darin bestand, die RXD0- und RXD1-Pins umzudrehen. Aus diesem Grund konnte ich Datenverkehr auf meinem Logikanalysator sehen, der jedoch von meiner MCU nicht dekodiert wurde.

Wie jemand betonte, sind die von mir verwendeten Magnete asymmetrisch und sollten nicht für Auto-MDI-X verwendet werden. Ich hatte keine Probleme. Ich gehe davon aus, dass eines von zwei Dingen passiert: - Die Magnete funktionieren nicht in der anderen Ausrichtung, aber da alles, was ich habe, Auto-MDI-X verwendet, bleibt mein Board im Wesentlichen in der Konfiguration fixiert, die funktioniert, während das andere Gerät eingeschaltet ist Das Kabel richtet seine Signale entsprechend aus. - Die Magnete bieten angesichts der kurzen Ethernet-Läufe eine geeignete Signalintegrität. Eine Langzeitanalyse würde jedoch höhere Paketverlustraten oder Probleme bei längeren Läufen zeigen.

Ehrlich gesagt ist mir nicht klar, warum es wichtig ist, auf welcher Seite des 1: 1-Transformators die Netzfilter installiert sind. Außerhalb von PoE-Anwendungen bin ich mir nicht sicher, warum ein symmetrisches oder asymmetrisches Design wichtig ist.

Sie haben Wireshark auf dem PC installiert und verwenden, wie Sie sagen, einen USB-zu-LAN-Adapter. Ich bin nicht sicher, an welchem ​​physischen Punkt Wireshark Pakete in Ihrem Setup erfasst, und daher ist es eine gute Frage, ob ausgehende Pakete tatsächlich auf dem Internet angezeigt werden physischen Netzwerk . Ich empfehle Ihnen, einen anderen PC mit Netzwerkschnittstelle anzuschließen und zu prüfen, ob diese PCs miteinander kommunizieren können, indem Sie die Ausgabe von Wiresharks auf ihnen vergleichen.

Ihre Wireshark-Ausgabe zeigt keine Probleme an. Der PC gibt dreimal bekannt, dass er sich im lokalen Netzwerk befindet und die IP-Adresse 10.0.0.1 hat (wenn er eine Antwort auf eine dieser 3 ARP-Anforderungen erhalten würde, würde das Betriebssystem mit einem IP-Adresskonflikt auftauchen).

Dann fragt Ihr Board ständig, wer 10.0.0.1 hat. Sagen Sie 10.0.0.2 und PC-Antworten mit 10.0.0.1 ist bei ... . Die Frage ist, warum es in Schleife passiert:

1. Die Karte empfängt kein vom PC gesendetes Antwortpaket.
2. Das Board erwartet etwas anderes oder das empfangene Paket ist beschädigt und verwirft das Paket.

Nehmen Sie als nächsten Schritt zur Fehlerbehebung einen anderen PC mit "normaler" Ethernet-Schnittstelle, installieren Sie Wireshark darauf, konfigurieren Sie das Netzwerk auf die gleiche Weise wie für das Board und versuchen Sie es telnet 10.0.0.1 80 sehen, dass es in Wiresharks auf beiden Computern angezeigt wird. Auf diese Weise stellen Sie sicher, dass der PC mit seinem USB-zu-Ethernet-Adapter ordnungsgemäß funktioniert.

Ihre nächsten Schritte hängen von den Dingen ab, die Sie in diesen Wiresharks sehen.

Aktualisieren:

Ich empfange Pakete, sonst würden die RXD0 / D1-Pins keine Aktivität anzeigen, richtig?

Nicht richtig. Sie möchten glauben, dass Ihr Board Pakete empfängt. Sie sehen, dass sich der Pegel der PHY-Eingangssignale etwas ändert, diese jedoch nicht unbedingt gültige Pakete darstellen. Die Tatsache, dass RX_ERR nicht umschaltet, überzeugt mich nicht sofort davon, dass PHY bei eingehenden Ereignissen ordnungsgemäß funktioniert oder dass eingehende Informationen die richtigen Pakete bilden.

Wie auch immer, es liegt an Ihnen, meine Theorie zur Fehlerbehebung ist einfach - Sie müssen auf höherer Ebene sicherstellen, wo Sie auf das Problem stoßen, und sich dann mit dem jeweiligen Teil des Entwurfs befassen. Es ist nutzlos, in alle Teile zu graben und alles zu vermuten. Es wäre ein großes Glück, wenn Sie Probleme finden würden, die den Fokus verbreiten. Sie versuchen bereits, die Software zu vereinfachen. Wenn dies nicht gelingt, werden Sie höchstwahrscheinlich damit beginnen, Chips auszutauschen.

Ich denke nicht, dass mein Schritt zur Fehlerbehebung so kompliziert ist, um sicherzustellen, dass ein anderer PC mit einem Dongle mit dem PC kommunizieren und mich als falsch oder richtig beweisen kann, und um sicherzustellen, dass Sie richtig in die Tiefe graben und vermuten, dass PHY, MAC und Software des Boards daran arbeiten Sie.

Es tut uns leid, dieses Thema wiederzubeleben. Ich konnte nicht bestehen, ohne meine Erfahrung zu erwähnen.

Ich habe diesen HR911105A (RJ45 mit Magnet) bei einem meiner Projekte verwendet.

HR911105A: Auf einen Blick fiel mir eines auf, nämlich die Verbindung zwischen LAN8720 und RJ45 gemäß Ihrem Schaltplan.

Da sehe ich, dass die Verbindung Crossover aussieht. Obwohl verbundene Systeme meistens MDI-X verwenden und daher Empfangs- / Sendepaare erkennen, wäre es gut, eine weniger verwirrende Verbindung wie diese zu geben:

LAN -> RJ45
=====================
TXP -> TD+ (Pin #1)
TXN -> TD- (Pin #2)
RXP -> RD+ (Pin #3)
RXN -> RD- (Pin #6)

Pin #4 and Pin #5(also die 49,9R-Pull-up-Widerstände) wären gut, wenn sie 3V3_ANin Ihrem Schaltplan angeschlossen wären, während die andere Seite über einen Kondensator (0,1 uF oder 0,022 uF) mit dem GND verbunden werden sollte.