Hallo,
ich habe ein Problem mit dem Phy, dass er keine Pakete empfängt.
Der Rx Error Pin wackelt ständig und der Error Zähler zählt munter hoch
im Phy Register.
Transmit funktioniert (ich sehe die gesendeten Pakete im Netzwerk).
Woran könnte das liegen? Ist die Ref Clock vielleicht zu ungenau?
Gemessen habe ich diese mit einem Oszi und lag bei 50MHz.
Peter
Peter schrieb:> Woran könnte das liegen?
Wie sollen wir das aus deinen extrem detaillierten Angaben
herausfinden?
Peter schrieb:> Ist die Ref Clock vielleicht zu ungenau?
Was hat die Uhr mit einem LAN8742A zu tun?
Peter schrieb:> Gemessen habe ich diese mit einem Oszi
Und damit kann man bei weitem nicht ausreichend genau eine
Frequenz messen, weder die eines Taktes (der Clock) noch
die einer Uhr (die Clock).
Es ist eine eigene Entwicklung.
Als Controller sient ein STM, der mit 100MHz läuft und über den MCO die
25MHz zum Phy ausgibt.
gemessen habe ich direkt an Pin 10 vom Phy.
Peter schrieb:> Es ist eine eigene Entwicklung.>> Als Controller sient ein STM, der mit 100MHz läuft und über den MCO die> 25MHz zum Phy ausgibt.
Der MCO ist das Problem. Die Signalqualität reicht nicht für Ethernet
aus.
Du solltest am Besten einen externen 50MHz Quarzoszillator mit
vorzugsweise 25ppm oder besser nehmen und den als Input für den PHY und
den MAC verwenden.
fchk
Also ich kenne Geräte da funktioniert das mit dem MCO ohne Probleme.
Wenn der GPIO richtig konfiguriert ist geht das. Das ist ein Takt der
vom MCU Quarz Takt abgeleitet ist, die MCU sollte natürlich mit Quarz
und nicht mit HSI laufen. In der SW kontrollieren auch auch wirklich der
externe Clock oder Xtal verwendet wird und nicht ein Fallback auf HSI
passiert.
Sind die R713/714 wirklich mit 22 R bestückt? In dem Bereich die
Lötstellen ok? Die Leitungen hier auch gleich lang?
Peter schrieb:> der Quarz hat 24MHz 10ppm und 25MHz kommen aus dem MCO Ausgang.
Das wird nicht gut sein, denn die Takterzeugung geht über
(mindestens) eine PLL die höchstwahrscheinlich einen Jitter
auf die 25 MHz einbringt und damit die Qualität für
Ethernet unzulänglich macht.
Ein Referenztakt für einen Controller braucht keine hohen An-
forderungen erfüllen, ein Ethernet Clock dagegen schon. Hier
ist oft schon eine hohe Frequenzabweichung eines Quarzes aus-
reichend damit nicht mehr alles fehlerfrei funktioniert.
Bei mir lasse ich den Ethernet-Takt immer separat per Quarz
oder Quarzoszillator erzeugen, die paar Cents sind doch völlig
egal.
Aber hier gibt es halt immer wieder mal die Geiz ist Geil
Mentalität, lauft darauf hinaus: Sparen, koste es was es wolle.
meiomei schrieb:> Ein Referenztakt für einen Controller braucht keine hohen An-> forderungen erfüllen, ein Ethernet Clock dagegen schon. Hier> ist oft schon eine hohe Frequenzabweichung eines Quarzes aus-> reichend damit nicht mehr alles fehlerfrei funktioniert.
Okay,
ich versuche zu erst den 24MHz durch einen 25MHz zu tauschen.
meiomei schrieb:> Aber hier gibt es halt immer wieder mal die Geiz ist Geil> Mentalität, lauft darauf hinaus: Sparen, koste es was es wolle.
In meinem Fall nicht oft spielt auch Platz eine Rolle
Peter schrieb:> meiomei schrieb:>> Aber hier gibt es halt immer wieder mal die Geiz ist Geil>> Mentalität, lauft darauf hinaus: Sparen, koste es was es wolle.>> In meinem Fall nicht oft spielt auch Platz eine Rolle
Der hier ist 2.5mm mal 2mm groß - wer Platzgründe vorschiebt, hat den
Blick für die Realität des Marktes nicht:
https://www.digikey.de/product-detail/de/epson/SG-210STF-50-0000MS3/SER3808CT-ND/4429411
Und es müssen 50 MHz sein und keine 25 MHz, damit Du den Takt direkt
verwenden kannst und nicht noch durch eine PLL durch musst, die Rauschen
hinzufügt.
fchk
Frank K. schrieb:> Und es müssen 50 MHz sein und keine 25 MHz,
50 MHz am Controller wird nicht gehen.
Und nein, es reichen 25 MHz am LAN8742A.
Siehe:
Johannes S. schrieb:> der LAN8742 hat doch selber eine PLL und läuft mit 25 MHz Quarz/ext.> Clock.
Wenn man allerdings vom Controller her 25 Mhz erzeugt wird es
wahrscheinlich zwangsläufig über eine PLL laufen, und dann ist
es der gleiche Mist wie vorher mit 24 MHz.
Also: wenn man sicher gehen will verfolgt man "die reine Lehre",
und die sagt: Quarzoszillator oder Quarz direkt am LAN8742A.
Also,
ich habe den Quarz nun gegen einen mit 25MHz getauscht und den HCLK auf
den PHY direkt (ohne PLL) geführt.
Die Frame Error sind weg, leider noch bekomme ich zumindest noch keine
DHCP Antwort.
Danke bis hier her
Womit erzeugst du denn das DHCP Request Paket?
Da es ein Broadcast ist kannste ja mal mit Wireshark an einem anderen
Rechner gucken ob es richtig aussieht.
wg. clock nochmal, möchte da auch nix falsches stehen lassen:
habe nochmal nachgesehen, da wo ich weiss das es mit MCO geht, da wird
für den µC (F407) auch ein Quarz Oszillator mit 25 MHz verwendet. Für
den MCO hat man da mehrere Quellen zur Auswahl, unter anderem HSE und
PLL. Hier ist HSE einstellt wg. passendem Takt, da ist die PLL also
nicht dran beteiligt. Bei 24 MHz HSE muss man natürlich durch die PLL,
und das wird dann etl. doch zuviel jitter für Ethernet. Bei 24 MHz sind
mehrere Faktor/Teiler Kombinationen möglich, vielleicht gibts doch
besser passende für einen stabilen MCO?
Mw E. schrieb:> Womit erzeugst du denn das DHCP Request Paket?> Da es ein Broadcast ist kannste ja mal mit Wireshark an einem anderen> Rechner gucken ob es richtig aussieht.
Genau so hatte ich es auch gemacht.
Der Server hatte den Request auch beantwortet.
Johannes S. schrieb:> wg. clock nochmal, möchte da auch nix falsches stehen lassen:> habe nochmal nachgesehen, da wo ich weiss das es mit MCO geht, da wird> für den µC (F407) auch ein Quarz Oszillator mit 25 MHz verwendet. Für> den MCO hat man da mehrere Quellen zur Auswahl, unter anderem HSE und> PLL...
Ich habe den Quarz heute gegen einen 25MHz Quarz getauscht. Die Clock's
passend eingestellt den MCO auf HSE gesetzt ohne Teliler und dann lief
es direkt ohne Frame Error.
UDP Pakete konnten gesendet und empfangen werden.