Ich habe ein Board erstellt um mit dem STM32F107 die Ethernet Schnittstelle zu benutzen. Dazu nutze ich den DP83826 als PHY im Basic mode mit RMII. Der DP83826 wird außerdem im Master mode benutzt. Der bekommt also vom STM32 seine 25MHz über den MCO Pin an seinem XI pin. Der PHY ist per Strap so konfiguriert, dass er aus den 25MHz seine 50MHz für das RMII macht. Das habe ich gemessen und an der TXCLK liegen 50MHz an.
Leider startet aber keine automatische Link negotiation. Das verbinden eines Kabels mit einem PC führt nicht dazu, dass am PC der Link als aktiv angezeigt wird.
Ich nutze STM32 Cube und würde hier gerne fragen, ob ich noch auf etwas spezielles achten muss. Ich habe per debugger auch mal überprüft ob der controller über MDIO mit dem PHY kommunizieren kann. Das funktioniert einwandfrei, denn man mann das Register 0x02 auslesen und es liefert den erwarteten Wert.
Muss ich dem PHY oder dem lwip stack eventuell irgendwo sagen, dass er in regelmäßigen abständen neu prüfen soll, ob etwas angeschlossen ist?
Da kommt bei mir gleich die Frage auf ob du jetzt das Jitter-
Problem des PHY-Taktes angemessen berücksichtig hast. Dazu
finde ich in deinem jetzigen Bericht nichts dazu:
Der DP83826 wird außerdem im Master mode benutzt. Der
bekommt also vom STM32 seine 25MHz über den MCO Pin an seinem XI pin.
Wenn also der MCO Pin deines Controllers intern von der PLL
gespeist wird dann hast du etwas falsch gemacht bzw. schon
damals die Problematik nicht richtig verstanden.
Wenn also der MCO Pin deines Controllers intern von der PLL
gespeist wird dann hast du etwas falsch gemacht bzw. schon
damals die Problematik nicht richtig verstanden.
Der MCO Pin wird direkt von HSE getrieben und nur die 25MHz durchgereicht. An der Stelle habe ich Unsinn geschrieben. Es ist keine PLL, die 25MHz generiert. An der Stelle habe ich mich an das Datenblatt gehalten und da wird diese Möglichkeit explizit genannt.
Jetzt kommt leider wieder die Salami-Thematik zu tragen ....
Wenn schon ein Schaltplan zu sehen wäre müsste man weniger
fragen ...
Aus den Datenblättern folgere ich dass die MAC-Einheit des
Controllers den 50MHz-Clock des PHY gespeist bekommen muss
(für den Fall der Konfiguration RMII). Der alternativ gespeiste
bzw. konfigurierte Pin heisst ETH_RMII_REF_CLK.
Hast du das berücksichtigt?
(soweit ich mich erinnere hatte ich das bei meiner Implementierung
für den F407 mehr oder weniger automatisch richtig gemacht
Beitrag "Re: STM32F107RBT6 Ethernet Clock")
Muss ich dem PHY oder dem lwip stack eventuell irgendwo sagen, dass er
in regelmäßigen abständen neu prüfen soll, ob etwas angeschlossen ist?
das hängt davon ab ob man FreeRTOS eingebaut hat oder ohne OS arbeitet. In beiden Fällen wird Code generiert der den NIC Status abfragt und ein IF up/down auslöst. Ohne OS muss in der main loop das MX_LWIP_Process aufgerufen werden. Man kann einen Callback für die Statusänderung angeben. lwip hat Timer die z.B. auch die DHCP und ARP Anfragen auslösen.
Was auch wichtig ist - wie sieht die Initialisierung aus im Code?
Irgendwo musst du den PHY ja auch initialisieren.
Wir haben zb den KSZ 8081 und ich meine mich zu erinnern, das bestimmte Modi als default laufen. Kommst du denn durch die Init Routinen von ST durch?
Trag mal die ganzen Infos hier zusammen.
Viele Grüße
Meine Implementierung zb sieht vor, das der Status der Negotiation entsprechend auch zyklisch beim PHY abgefragt werden muss und so bringst du dann die Info entsrpechend in die Software ein - in Abhängigkeit von den Registern im PHY.
Post doch mal den Treiber für den PHY zb.
Du kannst doch bestimmt auch einfach mal die Register zyklish lesen und ausgeben auf einer UART oder so und Inhalte mit dem Datenblatt abgleichen.
Ich initialisiere da nichts besonderes, da ich bei der Cube IDE davon ausgehe, dass das alles gemacht wird. Ich habe auch nachgeschaut und MX_LWIP_Process wird aufgerufen. Ich nutze kein FreeRTOS. Allerdings ist mir aufgefallen, dass ich kein Interrupt Pin verbunden habe aber der Code davon ausgeht. Ich finde allerings im Falle eines Interrupts nirgendwo code, der auf den Link Status reagiert.
Der Int wird nicht genutzt, dafür ist das MX_LWIP_Process, das erledigt alles per polling.
Im MW_LWIP_init wird auch der Phy Init auferufen, da kann man mit dem Debugger durchgehen.
Beim H7 habe ich das Problem das der zu schnell ist, der Phy init wird nach 3 ms aufgerufen, da hat der seine strapping bits noch nicht eingelesen und das Lesen des SR liefert -1 als Wert, aber keinen Fehler. In Folge läuft der Link mit 10 MBPS und half duplex, was dann keinen Datenaustausch erlaubt. Ist aber mit LAN8742. Es zeigt aber wie bescheiden der STM generierte Code an dieser Stelle ist. Weiteres Highlight ist, das der Phy init die Adressen 0...31 durchprobiert, obwohl der LAN8742 per strapping nur auf 0 oder 1 konfiguriert werden kann. Dann geht es weiter mit einer fixen Wartezeit von 2 s in der der Link ausgehandelt sein muss. Phy init liefert einen Fehlercode zurück, der wird aber einfach ignoriert.
Wenn man solche Sachen fixen möche, dann geht das nur indem man den Codegenerator abklemmt, der würde ja alles wieder überschreiben. Oder mühselig die Templates in der IDE Installation überschreiben...
Ich bin enttäuscht von dem Murks, hätte das für professioneller gehalten.
Und da haben wir noch nicht über das DMA/Cache Chaos geredet, das muss alles manuell konfiguriert werden.
angelegt, da darf man User Code reinschreiben. Diese Funktion muss aufgerufen werden wenn man das Netzwerkkabel zieht/steckt.
Diese wird für zusätzliche Aktionen aufgerufen, netif up/down behandelt lwip selber.
Ist das kein Thema mehr weil du das - ohne dich zu äussern -
bereits abgehandelt und für dich als nicht relevant betrachtet
hast? Oder hast du keine Lust dich mit potentiellen Problemen
bei der Hardware auseinanderzusetzen?
Ist das kein Thema mehr weil du das - ohne dich zu äussern -
bereits abgehandelt und für dich als nicht relevant betrachtet
hast? Oder hast du keine Lust dich mit potentiellen Problemen
bei der Hardware auseinanderzusetzen?
Ich habe etwas herumprobiert und nochmal geschaut was sein könnte. Es hat sich heruasgestellt, dass ich an dem RJ45 Verbinder mit integrierten Transformatoren den Shield nicht verbunden habe und den Center Tap mit einem Widerstand gegen 3.3V verbunden habe. Beides geändert und die Link Negotiation funktioniert. Leider kann ich aber noch keinen Ping zum Controller sende (ICMP ist aktiviert), da keine Pakete empfangen werden aber die Link up routine wird aufgerufen.
IP Adresse ist fix oder per DHCP? Man kann in lwip eine Menge Debugausgaben aktivieren, geht auch über die CubeMX Konfiguration.
Diese kommen dann über stdout raus, d.h. man braucht eine Routine die printf() möglich macht. Also z.B. einen UART aktivieren und _write() definieren
ICMP stammt ja vermutlich vom Ping, und diese Pakete werden
ja vom LWIP intern verarbeitet, treten also gar nicht auf
User-Level in Erscheinung.
Ich sollte aber auf einem Ping eine Antort erhalten und wenn ich mir in Wireshark anschaue was alles gesendet wird kommt nichts zurück. Allein schon die ARP Anfrage liefert keine Antwort, obwohl ARP aktiviert ist.
Auf low level ebene also in low_level_input() sollte ich sehr wohl alle einkommenden Pakete sehen
Auf low level ebene also in low_level_input() sollte ich sehr wohl alle
einkommenden Pakete sehen
richtig, da muss was ankommen.
Problem mit Rx Leitungen am Phy? Rx Paar auch richtig im CubeMX ausgewählt? Steht im EthernetIf.c in HAL_ETH_MspInit() im Kommentar was verwendet wird.
Problem mit Rx Leitungen am Phy? Rx Paar auch richtig im CubeMX
ausgewählt? Steht im EthernetIf.c in HAL_ETH_MspInit() im Kommentar was
verwendet wird.
Ich habe noch etwas mit dem Debugger herumgespielt um überhaupt mal ARP Request zu sehen. Es scheint, dass die Funktion HAL_ETH_GetReceivedFrame() niemals in einer der if Bedingungen springt und immer HAL_ERROR zurückgibt. Es wird also tatsächlich nichts empfangen.
Es wundert mich an der Stelle, ob das ein generelles Problem ist, wo doch Link negotiation nun funktioniert. Muss bei der Link Negotiation auch etwas an Daten übertragen werden?
was beim Link aushandeln genau passiert weiß ich auch nicht. Ist denn der gesendete ARP Request im Wireshark zu sehen? Wenn ja, sollte der Phy Clock ok sein.
Und es müsste am RXD0/1 liegen. Sind die PC4/5 vielleicht woanders in der Software wieder als GPIO definiert?
Software zeigen?
Und es müsste am RXD0/1 liegen. Sind die PC4/5 vielleicht woanders in
der Software wieder als GPIO definiert?
Habe ich schon geschaut PC 4 und PC 5 wird nirgendwo verwendet außer für ethernet. Welchen Teil des codes interessiert sich. Das ist bisher überwiegend generierter Code der STM32 IDE.
ich habe auch mal ein Projekt mit F107 generiert, der ist ja um einiges einfacher als ein F4 oder gar H7. Es gibt nur einen Speicherbereich und keinen Cache, alles Dinge die den Start ganz schön schwer machen können. Wenn etwas mit den Speicherbereichen für die Deskriptoren oder lwipHeap nicht stimmt, dann sollte es Hard- oder Memoryfault geben (mit dem Debugger kontrolliert das er da nicht landet?).
Von daher würde ich immer noch auf die HW tippen. Ansonsten ist der relevante Teil ja im LWIP Verzeichniss des Projektes (5 Dateien), den könntest du zeigen. MX_LWIP_Process wird im generierten Code nicht in der main loop eingetragen, das muss man selber machen und hast du ja auch gemacht.
Nur mal ein kurzes Update. Es war am Ende kein Softwareproblem, sondern diverse Lötbrücken, die schwer zu erkennen waren und ein nicht geroutetes CRS_DV Signal. Nachdem ich das provisorisch behoben habe funktioniert nun der PHY und die Kommunikation seht gut und ich kann das Gerät mit ICMP anpingen.
Der benutze PHY funktioniert übrigens mit den Standardeinstellungen aus der Cube IDE.
