Schaltung zwischen Wiznet W5500 und Ethernet Buchse

[Moot S. (mootseeker)]

Hallo Zusammen,

ich möchte einen Wiznet W5500 Chip von meiner Schaltung absetzten. Dies 
hat auch ohne Probleme geklappt. Ich habe den Chip mit einem Sockel auf 
eine Lochraster platte gelötet. Die Kommunikation über SPI Funktioniert 
auch (Konnte ich mit dem Logic auslesen).

Leider funktioniert die Kommunikation zum Switch nicht. Die Leitungen 
zwischen der Buchse und dem Wiznet sind auch relativ lange (ca. 10cm) 
und können so auch nicht gekürzt werden.


Nun ist meine Frage, brauch es die Markierten (siehe Bild im Anhang) 
Widerstände und C's zwischen der Buchse und dem Wiznet Chip?

Oder kann ich die Buchse praktisch fliegenden nahe am Chip anlöten?


Der Aufbau wird nur für einen Firmware Test benötigt, dem entsprechend 
sollte das angeschlossene Ethernet Kabel auch nicht länger wie 0.5m 
sein.


Vielen Dank schon im voraus für eure Antworten.

[Maxe (Gast)]

In der gegebenen Schaltung brauchst RJ45-Buchsen mit eingebauten 
Uebertragern (Magnetics).
Die Laenge des Patchkabels sollte meines Erachtens weniger eine Rolle 
spielen, viel mehr die Leitung zu den Uebertragern. Impedanzkontrolliert 
und so.

[Thorsten S. (thosch)]

Moot S. schrieb:
> Nun ist meine Frage, brauch es die Markierten (siehe Bild im Anhang)
> Widerstände und C's zwischen der Buchse und dem Wiznet Chip?

Ja!
Insbesondere bei den beiden Abschlußwiderständen ist wichtig, daß die am 
verbundenen Ende praktisch direkt aneinanderleigen und eine sehr kurze 
Anbindung an den im Schaltplan darunterliegenden 10nF Kondensator haben.

Ganz wichtig auch: Die Buchse ist keine einfache RJ45-Buchse, sondern 
muß eine mit eingebauten Trafos+Drosseln sein, also eine Buchse mit 
"integrated magnetics", was die Bezeichnung "MAGJACK" verdeutlicht.

Die Leitungen zur Buchse müssen als differenzielle Leitungspärchen mit 
kontrollierter Impedanz (100Ω differenziell) geroutet werden.

Das Datenblatt vom W5500:
http://wizwiki.net/wiki/doku.php/products:w5500:datasheet

Die Standard-Schaltung incl. geeigneter Trafos / Magjacks findet sich 
hier:
http://wizwiki.net/wiki/doku.php/products:w5500:refschematic

Vielleicht holst du dir besser ein WIZ550io Modul, das ist der 
"abgesetzte" W5500 Chip mit sämtlicher Beschaltung incl. RJ45-Buchse mit 
integrierten magnetics.
http://wizwiki.net/wiki/doku.php/products:wiz550io:start

[Moot S. (mootseeker)]

Oke vielen Dank für die Antwort.

Dann muss ich mir wohl noch was einfallen lassen. Ich möchte eben den 
Wiznet Chip Sockeln damit ich diesen tauschen kann für meine Tests. Aber 
dann werde ich dies mal fliegend versuchen und sonst muss ich mir halt 
was anderes einfallen lassen.

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Bei mir ging anfangs auch keine Kommunikation.
Quarz raus, oszillator dran und schon ging alles.

73

[Thorsten S. (thosch)]

Moot S. schrieb:
> Dann muss ich mir wohl noch was einfallen lassen. Ich möchte eben den
> Wiznet Chip Sockeln damit ich diesen tauschen kann für meine Tests.

Sockeln ist bei so einem Chip eine ganz schlechte Idee!
Die Abblockkondensatoren an den Versorgungsanschlüssen müssen so kurz 
wie irgend möglich an den Pins plaziert werden, damit sie ihre Aufgabe 
erfüllen können.
Dafür am Ende gar noch eine Adapterplatine von LQFP-48 auf Pins im 
2,54mm-Raster zu verwenden, ist praktisch die Garantie für 
Nichtfunktion.
Die Leitungslängen der Abblockkondensatoren bis zu den IC-Pins sollten 
3mm  ( notfalls 5mm) nicht überschreiten, im Falle einer Adapterplatine 
hätte man nur dann eine Chance, wenn die Kondensatoren auf der 
Adapterplatine direkt vor den Versorgungspins des W5500 bestückt werden.
Leiterbahn- und Steckpinlänge würden die Kondensatoren viel zu weit vom 
IC entfernen und wirkungslos machen.

Zeig doch mal ein Foto von deinem bisherigen Aufbau.

[Heisser Finger (Gast)]

Thorsten S. schrieb:
> Sockeln ist bei so einem Chip eine ganz schlechte Idee!

Zudem die W5xxx Chips richtige Stromfresser sind die auch
eine gute Wärmeabführung brauchen. Dabei hilft die flache
Montage auf der Leiterplatte. "Freifliegender" Betrieb
mach die Sache sicher nicht kühler.

[Moot S. (mootseeker)]

Thorsten S. schrieb:
> Sockeln ist bei so einem Chip eine ganz schlechte Idee!

Das ist mit natürlich schon klar. Ich muss das aber so machen, da ich 
einen Bug im Init einen Fehler habe, welcher nur mit einem "Frischen" 
Chip erscheint. Deswegen muss ich den Chip einfach Wechseln können. Das 
mache ich mit einem Sockel.

Ein Bild kann ich nachher noch posten :)

[Sebastian W. (wangnick)]

Moot S. schrieb:
> Das ist mit natürlich schon klar. Ich muss das aber so machen, da ich
> einen Bug im Init einen Fehler habe, welcher nur mit einem "Frischen"
> Chip erscheint. Deswegen muss ich den Chip einfach Wechseln können. Das
> mache ich mit einem Sockel.

Versteh ich nicht. Häng den W5500 doch an einen separaten Linearregler 
mit EN-Eingang, den du vom UC aus ansteuerst (etwa so wie 
https://s.wangnick.de/doku.php?id=iot-basisstation).

LG, Sebastian

[Moot S. (mootseeker)]

Ähm nein? ich brauche für meine Tests "frische" Chips. Das heisst welche 
die noch nie angesteuert wurden.

[Sebastian W. (wangnick)]

Moot S. schrieb:
> Ähm nein? ich brauche für meine Tests "frische" Chips. Das heisst welche
> die noch nie angesteuert wurden.

Spannend. Du meinst also, dass sich noch nie angesteuerte W5500 von 
welchen die schon einmal angesteuert wurden unterscheiden?

LG, Sebastian

[Esode Rigger (Gast)]

Sebastian W. schrieb:
> Spannend.

Ja, offensichtlich gibt es magische Software die es schafft,
Hardware kaputtzusteuern.

Früher, zu MS-DOS-Zeiten, war das noch schlimmer: wenn man
raubkopierte Software auf seinem eigenen Rechner startete
führte dies dazu dass der eigene Bildschirm explodierte
oder die Grafik-Karte dahin schmolz.

So wurde zumindest vom "geschädigten" Software-Hersteller gedroht.

[Maxe (Gast)]

Naja, die Moeglichkeit , dass etwas ins Flash/Eeprom geschrieben wird, 
das die darauffolgende Initialisierung beeinfluss, besteht schon.

Das Sockeln kann aber doch keine 10cm Leiterlaenge verursachen.

[Spess53 (Gast)]

Hi

>Naja, die Moeglichkeit , dass etwas ins Flash/Eeprom geschrieben wird,
>das die darauffolgende Initialisierung beeinfluss, besteht schon.

Im Datenblatt steht aber weder etwas von Flash- noch von EEPROM-Memory. 
Lediglich etwas von Registern. Genau wie beim Wv5100 und W5200.

Ich glaube der TO veralbert uns.

MfG Spess

[Stefan F. (Gast)]

Esode Rigger schrieb:
> wenn man
> raubkopierte Software auf seinem eigenen Rechner startete
> führte dies dazu dass der eigene Bildschirm explodierte
> oder die Grafik-Karte dahin schmolz.

Laber doch keinen Schwachsinn!

[Esode Rigger (Gast)]

Stefan ⛄ F. schrieb:
> Laber doch keinen Schwachsinn!

Keine Ahnung was früher so "gehandelt" wurde?
Gehst zum Lachen auch in den Keller, wa?

[Moot S. (mootseeker)]

Die Leitungen habe ich nun alle auf ein minimum gekürzt.
Leider funktioniert der Aufbau immer noch nicht.

Im Anhang habe ich noch die Bilder vom Aufbau.

Auf den Bildern seht ihr den Sockel auf einer Lochraster Platte. Die 
Pins welche Pullups oder C's haben sind direkt auf der Lochraster Platte 
angeschlossen, die anderen Daten Leitungen für SPI sind auf die 
Stiftleiste geführt. Die RX/TX Leitungen für Ethernet sind auf das 
ausgeschnittene PCB geführt, dort ist alles für die Buchse drauf 
(Kopplungs C's und Widerstände). Der Quarz sitzt in der Mitte des 
Sockels und ist mit einem kleinen Ferritplättchen vom IC abgeschirmt 
(weiss nicht ob das wirklich etwas bringt...) damit sind die Leitungen 
ein paar mm lang.

Speisung und SPI kommen über die Stiftleisten. Die SPI Kommunikation 
funktioniert gut, MAC Adresse wie andere Register können gelesen werden.
Eine Verbindung mit dem Switch kann nicht aufgebaut werden. Die grüne 
Led an der Buchse (ACT-LED) leuchtet immer und die andere (LINK-LED) 
leuchtet oder blinkt garnicht.

Funktioniert die SPI auch ohne Quarz? Dann wäre die Baustelle natürlich 
noch viel grösser.

Die langen Leitungen die noch weggehen sind die Pins welche auf die 
LED's der Buchse gehen.

[Sebastian W. (wangnick)]

Hi Moot,

der Aufbau ist ... künstlerisch, insbesonders die 
twisted-pair-Verkabelung der Buchse! Gut das bei Ethernet der 
Verdrillungsgrad nicht spezifiziert ist :)

Wenn die Kommunikation mit dem MCP2515 über SPI jetzt funktioniert, dann 
wäre mein nächster Schritt die Prüfung der Autonegotiation 
(https://de.wikipedia.org/wiki/Autonegotiation) auf der physischen 
Leitung mit Oszi o.Ä.

Hast du eventuell eine Ethernet-Gegenstelle bei der du einen Port fest 
auf 10Mbit einstellen kannst? Vielleicht funktioniert das schon.

Und bitte noch kontrollieren, ob die Buchse die 1:1-Transformatoren 
eingebaut hat, sonst hast du noch einen ganzen anderen Sack von 
Problemen ...

LG, Sebastian

PS: SPI ist nicht soo frequenzkritisch, alle richten sich eh nach den 
SCK-Flanken ...

PPS: Warum fertigst du die nicht eine Platine auf der du den Sockel, die 
Buchse und das Hühnerfutter montierst?

PPPS: Anbei zur allgemeinen Erheiterung Bilder meines entsprechenden ... 
Kunstwerks (von 2013), das allerdings dennoch funktioniert hat.

[Moot S. (mootseeker)]

Einstellen kann ich die gegenstelle leider nicht. Aber die 
Transformatoren in der Buchse sind 1:1.

Sebastian W. schrieb:
> PPS: Warum fertigst du die nicht eine Platine auf der du den Sockel, die
> Buchse und das Hühnerfutter montierst?

Weil ursprünglich war die Idee, dass es so schnell wie möglich gehen 
sollte.
Da ich diesen Bug für ein Projekt hätte lösen sollen.

Sebastian W. schrieb:
> PPPS: Anbei zur allgemeinen Erheiterung Bilder meines entsprechenden ...
> Kunstwerks (von 2013), das allerdings dennoch funktioniert hat.

Wahrscheinlich sind bei mir alle Leitungen viel zu lang. Vielleicht wäre 
eine fertige Platte aus China nicht ein mal das blödeste ^^

[Sebastian W. (wangnick)]

Moot S. schrieb:
> Wahrscheinlich sind bei mir alle Leitungen viel zu lang. Vielleicht wäre
> eine fertige Platte aus China nicht ein mal das blödeste ^^

Ethernet arbeitet bei 33MHz, das is jetzt noch nicht soo kritisch. Aber 
die Link-Aushandlung passiert mit einem viel langsameren Protokoll (33 
Pulse 100ns lang und im Abstand von ~60us, siehe 
https://de.wikipedia.org/wiki/Autonegotiation), und wenn die nicht 
funktioniert dann liegt es eher nicht an der Leitungslänge ...

LG, Sebastian

[Moot S. (mootseeker)]

Sebastian W. schrieb:
> und wenn die nicht
> funktioniert dann liegt es eher nicht an der Leitungslänge

Ich habe nun versucht dies zu messen, muss ich etwas speziell beachten, 
weil ich kann nichts messen auf der Leitung.

[Sebastian W. (wangnick)]

Moot S. schrieb:
> Ich habe nun versucht dies zu messen, muss ich etwas speziell beachten,
> weil ich kann nichts messen auf der Leitung.

Ich zeichne mal die Signale des W5500 auf und berichte dann ...

LG, Sebastian

[PCB (Gast)]

Von den W5500 gab es unterschiedliche Revisionen. Wir hatten mit der 
älteren Revision auch mal Init-Probleme.
Es gibt da irgendwo ein Errata zu.

[Sebastian W. (wangnick)]

Sebastian W. schrieb:
> Ich zeichne mal die Signale des W5500 auf und berichte dann ...

Ok, hier die Messungen ohne Kabel. In Bild 02 sieht man den 
FLP-Impulsdatenstrom (link code word) 1000011110000000:
 - 10000: IEEE 802.3
 - 1: Kann 10BASE-T Half Duplex
 - 1: Kann 10BASE-T Full Duplex
 - 1: Kann 100BASE-T Half Duplex
 - 1: Kann 100BASE-T Full Duplex
 - 1: Kann nicht 100BASE-T4
 - 0: Pause?
 - 0: Asymetric pause for full duplex?
 - 0: Reserved
 - 0: No remote fault detected
 - 0: No acknowledgement of remote link code word
 - 0: No next page

Bei Bild 04 bitte beachten, dass die Samplingrate nur 50MS/s betrug, und 
dass die Anzeigesoftware daraus "schöne sanfte" Kurven macht. Die echte 
Dauer des Differentialimpulses wird wohl näher an den spezifizierten 
100ns liegen ...

LG, Sebastian

[Moot S. (mootseeker)]

Sebastian W. schrieb:
> Ok, hier die Messungen ohne Kabel.

WOW vielen Dank für die Messungen.
Ich werde es nochmals versuchen zu messen und vergleiche es mit deinen 
Messungen, da bei mir nur eine gerade Linie war. Habe aber inzwischen 
aber nochmals etwas nachgelötet Weils nicht so gut gehalten hatte, evtl. 
auch keinen sauberen kontakt gemacht.

[Spess53 (Gast)]

Hi

>Ähm nein? ich brauche für meine Tests "frische" Chips. Das heisst welche
>die noch nie angesteuert wurden.

Die Aussage ist blanker Unsinn. Bei einen Reset werden alle Register 
zurückgesetzt und der W5500 ist wieder jungfräulich. Also was soll der 
ganze Unsinn?

MfG Spess

[Chregu (Gast)]

Und in der Herstellung wurden die natürlich auch nie getestet...

[Moot S. (mootseeker)]

Spess53 schrieb:
> Die Aussage ist blanker Unsinn.

Dann erklär mir mal folgendes Problem:

Ich habe Firmware A mit der funktioniert alles Super.
Bei Firmware B funktioniert das init des Wiznet nicht korrekt.
Flashe ich zuerst Firmware A lasse sie laufen und danach Firmware B 
funktioniert das init des Wiznet auch bei B.

Auch wenn ich Firmware A flashe, einen Reset mache (Alle Register 
sollten deiner Meinung nach gelöst sein) und dann Firmware B flashe 
funktioniert Firmware B ohne Probleme.

Löte ich den Chip aus und tausche ihn gegen einen anderen funktioniert 
Firmware B nicht. Damit ich aber nicht die ganze Zeit den Chip auslöten 
muss, wollte ich diesen Adapter bauen, damit es etwas schneller geht.

Wenn es ja so Unsinn ist, dann erklär mir wieso es nur so Funktioniert.

[Sebastian W. (wangnick)]

Hallo Moot,

Moot S. schrieb:
> Wenn es ja so Unsinn ist, dann erklär mir wieso es nur so Funktioniert.

Programmierst du die Firmware eventuell über SPI? Dann könnte der 
fehlende CS-Pullup dazu führen dass der W5500 beim Flashen "mithört" und 
den dann folgenden Reset-Befehl nicht versteht.

Ansonsten besteht natürlich auch die vage Möglichkeit, dass der Reset 
den Grundzustand nicht sauber wiederherstellt. Daher mein Vorschlag 
oben, dem W5500 einen eigenen, schaltbaren Linearregler zu spendieren, 
um im Zweifelsfall einen Power Cycle durchführen zu können. Dabei darauf 
achten auch CS, MOSI und SCK auf GND zu ziehen oder hochohmig zu machen, 
damit der W5500 nicht über seine Eingangsport-Schutzdioden weiter mit 
Strom versorgt wird.

Aber wenn du einen bestimmten W5500, den du in den Fehlerzustand 
gebracht hast, aus deinem Sockel nimmst und dann denselben W5500 wieder 
einsetzt, zeigt dieser bestimmte W5500 dann wirklich IMMER NOCH den 
Fehler, ein anderer "frischer" W5500 jedoch nicht? Nur dann wäre ja ein 
Power Cycle nutzlos und nur ein Ersatz des W5500 die einzige Lösung. Das 
wäre allerdings wirklich äußerst seltsam ...

LG, Sebastian

[beo bachta (Gast)]

Spess53 schrieb:
> Die Aussage ist blanker Unsinn.

Sebastian W. schrieb:
> Aber wenn du einen bestimmten W5500, den du in den Fehlerzustand
> gebracht hast, aus deinem Sockel nimmst und dann denselben W5500 wieder
> einsetzt, zeigt dieser bestimmte W5500 dann wirklich IMMER NOCH den
> Fehler, ein anderer "frischer" W5500 jedoch nicht?

Bei soviel Esoterik und schwarzer Magie fehlen einem einfach die Worte.

[Sebastian W. (wangnick)]

beo bachta schrieb:
> Bei soviel Esoterik und schwarzer Magie fehlen einem einfach die Worte.

Kristallbeschwörung und Metallfolien die sich nur fast berühren ... :)

LG, Sebastian

[Moot S. (mootseeker)]

Sebastian W. schrieb:
> Programmierst du die Firmware eventuell über SPI?
Ich verwende einen PIC24 als MCU und programmiere die Firmware über die 
ICSP Schnittstelle.

Sebastian W. schrieb:
> Ansonsten besteht natürlich auch die vage Möglichkeit, dass der Reset
> den Grundzustand nicht sauber wiederherstellt.
Aber der Zustand des Reset ist doch nicht Firmware Abhängig? Wenn der 
Reset nicht sauber funktioniert dürfte es ja garnicht gehen... Oder 
verstehe ich das falsch?

Die Reset Flanken habe ich noch gemessen und die sehen Sauber aus.


Aber ihr seit der Meinung, dass das tauschen oder einen sauberen Reset 
des Chips keinen Unterschied machen müsste?


Ein bekannter hatte noch die Idee, dass ich evtl. ein Adress Problem in 
der Firmware habe und mit dem neuen Teil der Firmware B etwas am Anfang 
beim Init überschreibe. Das Hörte sich für mich eigentlich noch möglich 
an.
Dann würde ich nähmlich einfach einen Funktionierenden Print nehmen und 
mit dem weiter arbeiten.

[Sebastian W. (wangnick)]

Hi Moot,

Moot S. schrieb:
> Aber ihr seit der Meinung, dass das tauschen oder einen sauberen Reset
> des Chips keinen Unterschied machen müsste?

Das Tauschen des W5500, das Herausnehmen und wieder einsetzen des selben 
W5500, und ein sauberer Power Cycle eines W5500 werden sich mit hoher 
Sicherheit nicht voneinander unterscheiden.

Ein sauberer W5500 Reset, ob per RST-Leitung oder per SPI-Kommando, 
sollte sich von einem Power Cycle auch nicht unterscheiden. Aber PCB 
schrieb im Beitrag #6559097:
> Von den W5500 gab es unterschiedliche Revisionen. Wir hatten mit der
> älteren Revision auch mal Init-Probleme.
> Es gibt da irgendwo ein Errata zu.

Wenn du ausschliessen möchtest, das deinen Problem auf diese ominöse 
Ursache zurückgeht, dann entweder sockeln (mit einem Satz anderer 
Probleme wie du siehst) oder in deiner Schaltung vorsehen dem W5500 den 
Saft abzuklemmen, danach wird der W5500 im Grundzustand sein.

Die Wahrscheinlichkeit, dass bei deinen W5500 ein sauberer Reset NICHT 
den Grundzustand wiederherstellt ist meiner Meinung nach aber 
verschwindend gering. Du solltest also wohl in der Tat nach anderen 
Ursachen deines Problems suchen.

LG, Sebastian

[Stefan F. (Gast)]

Normalerweise sollte der Reset den Chip sauber zurück setzen. Wenn das 
fehlerhaft implementiert wurde, dann sollte spätestens ein Power-Cycle 
alles wieder zurück setzen.

Hast du eventuell irgendein von außen (aus Sicht des IC) kommendes 
Signal, dass Spannung führt, während der Chip keine Stromversorgung hat? 
Das wäre ein verbotener Zustand, bei dem ich mir so ein Fehlverhalten 
vorstellen kann.

[Moot S. (mootseeker)]

Sebastian W. schrieb:
> Du solltest also wohl in der Tat nach anderen
> Ursachen deines Problems suchen.

Ich werde wohl nochmals zum Anfang zurück gehen müssen und das Problem 
nochmals von vorne Analysieren.

Stefan ⛄ F. schrieb:
> Hast du eventuell irgendein von außen (aus Sicht des IC) kommendes
> Signal, dass Spannung führt, während der Chip keine Stromversorgung hat?
> Das wäre ein verbotener Zustand, bei dem ich mir so ein Fehlverhalten
> vorstellen kann.

Spannungen wie auch die Signale scheinen zu Stimmen.


Vielen Dank für eure Hilfe, ich melde mich wieder wenn ich etwas neues 
gefunden habe. Mit euren Antworten scheint das Problem wirklich nicht am 
Wiznet zu sein, sonder es muss etwas anderes sein. Momentan scheint ein 
Firmware bug für mich am logisten aber ich werde das nun nochmals 
prüfen.

[Moot S. (mootseeker)]

Kann mir jemand nun das folgende Problem erklären:

Ich habe die Firmware raufgespielt welche immer das Problem hat wenn man 
sie mit einem frischen Wiznet Chip benützt. Dabei habe ich einen Reset 
programmiert der Wie im Datenblatt steht > 500us sein muss. Der Reset 
dauert 100ms (Siehe Bild). Nach der Behauptung dass der Reset das 
gleiche macht wie einen Chip tauschen, sollte die Firmware nicht 
funktionieren.
Aber der Wiznet kann sich mit dem Switch verbinden und bekommt über DHCP 
eine IP-Adresse.

Wie kann das sein?

[Sebastian W. (wangnick)]

Moot S. schrieb:
> Ich habe die Firmware raufgespielt welche immer das Problem hat wenn man
> sie mit einem frischen Wiznet Chip benützt.

Ich verstehe nicht ganz. Welches Problem hat die Firmware mit einem 
"frischen" W5500? Kein Link? Oder keine IP-Adresse vom DHCP?

> Dabei habe ich einen Reset
> programmiert der Wie im Datenblatt steht > 500us sein muss. Der Reset
> dauert 100ms (Siehe Bild). Nach der Behauptung dass der Reset das
> gleiche macht wie einen Chip tauschen, sollte die Firmware nicht
> funktionieren.

Was passiert wenn du anstelle des Resets den W5500 -- oder deinen ganzen 
Versuchsaufbau - kurz stromlos machst? Erscheint dann wieder das 
Problem? Oder beobachtest du das Problem bei jedem deiner W5500 nur 
genau einmal bei der ersten Inbetriebnahme?

> Aber der Wiznet kann sich mit dem Switch verbinden und bekommt über DHCP
> eine IP-Adresse.

Kannst du den Ethernet-Verkehr des W5500 aufzeichnen? (Ich benutze zu 
Hause als Switch die GS105E/GS108E-Reihe von Netgear, die den Verkehr 
auf bestimmten Ports an einen anderen Monitoringport spiegeln kann, und 
dann auf dem dort angeschlossenen PC Wireshark ...)

LG, Sebastian

[Moot S. (mootseeker)]

Sebastian W. schrieb:
> Ich verstehe nicht ganz. Welches Problem hat die Firmware mit einem
> "frischen" W5500? Kein Link? Oder keine IP-Adresse vom DHCP?

Wenn die Fehlerhafte Firmware mit einem "frischen" W5500 betrieben wird, 
bekommt der W5500 keine IP-Adresse und bleibt in einem Loop hangen wo 
immer wieder der DHCP angesprochen wird. Bis der W5500 eine IP-Adresse 
bekommen hat.

Sebastian W. schrieb:
> Erscheint dann wieder das
> Problem?

Solange ich nicht die Funktionierende Firmware Programmiere habe ich 
immer das Problem.
Ich habe als versuch in der zwischen Zeit noch folgendes ausprobiert:

- Den Reset länger machen von 100ms zu 200ms zu 500ms - hat nichts 
gebracht.

- Der W5500 ist in der Speisung von einem separaten Regler gespiesen 
welchen ich per FW Ein-/Ausschalten kann. diesen habe ich auch 
Ausgeschalten und wieder Eingeschalten als stromloser Reset - hat aber 
auch nicht geholfen

Sebastian W. schrieb:
> Kannst du den Ethernet-Verkehr des W5500 aufzeichnen?

Ich habe mir mal einen Adapter gebastelt den ich dazwischen hängen kann. 
Ich versuche mal ob ich etwas heraus finden kann. Müsste ja eigentlich 
mit dem DHCP Filter etwas sehen?

[Sebastian W. (wangnick)]

Moot S. schrieb:
> Wenn die Fehlerhafte Firmware mit einem "frischen" W5500 betrieben wird,
> bekommt der W5500 keine IP-Adresse und bleibt in einem Loop hangen wo
> immer wieder der DHCP angesprochen wird. Bis der W5500 eine IP-Adresse
> bekommen hat.

Programmiert die Fehlerhafte Firmware (FeF) eventuell eine ungültige 
MAC-Adresse, die Funktionierende Firmware (FuF) dagegen ein gültige? 
Dann kann es EVENTUELL sein, dass der Ethernet-Switch bei Rückkehr zur 
FeF die Zuordnung des Port zu der vorherigen gültigen MAC-Adresse in der 
SAT beibehält und dadurch die Antwortpakete von ARP und DHCP an den 
W5500-Port weiterleitet ...

Probier mal den Ethernet-Switch aus- und wieder einzuschalten und dann 
mit der FeF zu starten. Wenn das dann reproduzierbar nicht funktioniert 
sind wir einen Schritt weiter ...

LG, Sebastian

[Moot S. (mootseeker)]

Sebastian W. schrieb:
> Programmiert die Fehlerhafte Firmware (FeF) eventuell eine ungültige
> MAC-Adresse, die Funktionierende Firmware (FuF) dagegen ein gültige?

In beiden Firmwaren wird exakt die selbe MAC Adresse geschrieben.
Das Schreiben der Firmware sehe ich über den Logic.
Ich kann auch die Firmware wieder auslesen und kann sie Korrekt auf der 
MISO Leitung erkennen.

Der Fehler ist übrigens Geräte unabhängig und erscheint auf allen 
Geräten mit neuem Chip.


Ich habe noch versucht mit Wireshark etwas auszulesen. Mit der 
funktionierenden Firmware kann ich die DHCP Anfrage / Antwort sehen.
Mit der nicht funktionierenden Firmware sehe ich nichts.

[Marco H. (damarco)]

Die Bastelei kann du dir sparen... Das Ding hat zur PHY einen eigenen 
Clock um die 25MHZ für die PHY zu generieren. Wenn da was faul ist 
bekommst du keine Kommunikation zur Ethernet Seite zu Stande. Register 
ausgelesen -> no link. So eiert der Code in der Schleife und wartet auf 
den link... Es gibt keinen Grund das Teil auf einen Sockel zu basteln. 
Außer man will das es nicht funktioniert...

[Sebastian W. (wangnick)]

Mmh, tricky.

Moot S. schrieb:
> In beiden Firmwaren wird exakt die selbe MAC Adresse geschrieben.
> Das Schreiben der Firmware sehe ich über den Logic.
> Ich kann auch die Firmware wieder auslesen und kann sie Korrekt auf der
> MISO Leitung erkennen.

Ok, zum korrekten Verständnis:
1. Beide Firmware-Versionen (FeF und FuF) beschicken den W5500 über 
RST-Leitung und dann SPI-Leitungen (also CS, MISO, MOSI, SCK) in genau 
derselben Weise.
2. Die Firmware selbst wird nach dem Schreiben zurückgelesen und als 
korrekt verifiziert.

Ich kenne mich mit dem PIC24 und dessen ICSP-Schnittstelle zur 
Firmware-Programmierung nicht aus, aber du erwähnst MOSI -- benutzt 
diese ICSP-Schnittstelle eventuell dieselben Leitungen wie die 
SPI-Schnittstelle zum W5500? Und wenn ja, kannst du dann bestätigen dass 
die CS-Leitung zum W5500 einen Pullup-Widerstand zu VCC bekommen hat, 
der verhindert dass der W5500 beim Firmware-Programmieren "mithört"?

Moot S. schrieb:
> Ich habe noch versucht mit Wireshark etwas auszulesen. Mit der
> funktionierenden Firmware kann ich die DHCP Anfrage / Antwort sehen.
> Mit der nicht funktionierenden Firmware sehe ich nichts.

Du solltest in Wireshark vor der DHCP-Komunikation eigentlich auch noch 
ARP-Pakete sehen ...

LG, Sebastian

[foobar (Gast)]

> Ich habe Firmware A mit der funktioniert alles Super.
> Bei Firmware B funktioniert das init des Wiznet nicht korrekt.

Dann wäre der offensichtliche Weg, zu schauen, was A anders macht als B. 
Davon sehe ich hier im Thread nichts ...

[Moot S. (mootseeker)]

Sebastian W. schrieb:
> 1. Beide Firmware-Versionen (FeF und FuF) beschicken den W5500 über
> RST-Leitung und dann SPI-Leitungen (also CS, MISO, MOSI, SCK) in genau
> derselben Weise.

Ja

Sebastian W. schrieb:
> 2. Die Firmware selbst wird nach dem Schreiben zurückgelesen und als
> korrekt verifiziert.

Ja

Sebastian W. schrieb:
> ICSP-Schnittstelle eventuell dieselben Leitungen wie die
> SPI-Schnittstelle zum W5500?

Nein, das ist eine Separate Schnittstelle nur zum Programmieren. Der 
W5500 hängt alleine an der SPI2.

Sebastian W. schrieb:
> Du solltest in Wireshark vor der DHCP-Komunikation eigentlich auch noch
> ARP-Pakete sehen ...

Bei mir sehe ich garnichts. Das Gerät sendet garnichts raus und wenn 
schon wird es vom Wireshark nicht erkannt.

[Moot S. (mootseeker)]

foobar schrieb:
> Dann wäre der offensichtliche Weg, zu schauen, was A anders macht als B.
> Davon sehe ich hier im Thread nichts ...

Ja das ist nicht so einfach wie gesagt.
Das Init des Wiznet ist in beiden Firmwaren 1:1 gleich. Man kann beide 
Firmware Projekte mit WinMerge untersuchen und das Programm zeigt nichts 
relevantes an (ausser natürlich unterschiedlichem Datum im Header usw).

[foobar (Gast)]

>> 2. Die Firmware selbst wird nach dem Schreiben zurückgelesen und als
>> korrekt verifiziert.
>
> Ja

Nur zur Info: das reicht nicht.  Der Brenner überprüft nur das, was er 
geschrieben hat.  Wenn die Firmware unvollständig ist (z.B. eine Zeile 
im hex fehlt, oder eine Section aus dem elf vergessen), sagt der Brenner 
immer noch, dass alles ok ist.

[foobar (Gast)]

> Das Init des Wiznet ist in beiden Firmwaren 1:1 gleich.

Wenn es nicht der Init-Code direkt ist, kann es irgendwas in der 
Umgebung sein, z.B. anders programmierter Timer oder I/O-Pin, anderer 
Zeitpunkt, an dem der Init begonnen wird, andere Fuses, undefinierte 
Zugriffe, ...

Wenn man es in der Software nicht findet, ggfs mit dem Logic-Analyzer 
die komplette Init-Sequenz auf dem SPI-Bus vergleichen (inkl Timing!).

[Christian H. (netzwanze)]

Moot S. schrieb:
> Ich habe noch versucht mit Wireshark etwas auszulesen. Mit der
> funktionierenden Firmware kann ich die DHCP Anfrage / Antwort sehen.
> Mit der nicht funktionierenden Firmware sehe ich nichts.

Wirklich Nichts, oder nur keine DHCP-Anfragen?

Meldet die Switch überhaupt einen Link?
Hängt noch etwas anderes an der Switch dran? Ist sie eventuell 
managementfähig? Dann müsste zumindest irgend etwas erscheinen. 
Zumindest ARP-Pakete von den anderen Geräte müssten da sein.

[Stefan F. (Gast)]

Wenn der Switch nicht in den transparenten Modus geschaltet werden kann 
(nicht jeder unterstützt das) kannst du mit Wireshark nur den eigenen 
Traffic deines PC schnüffeln.

Aber du könntest den Wiznet Chip direkt an deinen PC anschließen und 
diesen als DHCP Server verwenden. Dann hast du vollen Zugriff auf die 
Kommunikation.

Sebastian hat mich auf eine Idee gebracht.

Was ist, wenn der Chip mit der guten Firmware eine IP-Adresse aushandelt 
und danach mit der schlechten Firmware nur zuvor ausgehandelte IP 
Adressen nutzen kann? Das wäre dann ein Bug im DCHP Client oder ein Bug 
woanders, welcher den DHCP Client stört.

Wenn du den Chip auswechselst, dann hat der neue sicher eine andere (aus 
Sicht deines Routers jungfräuliche) MAC Adresse oder?

[Moot S. (mootseeker)]

Christian H. schrieb:
> Wirklich Nichts, oder nur keine DHCP-Anfragen?

Im Wireshark kommt nichts.

An der Buchse des Gerätes leuchten beide LED's. Am Switch sehe ich auch 
nichts.

foobar schrieb:
> Umgebung sein, z.B. anders programmierter Timer oder I/O-Pin, anderer
> Zeitpunkt, an dem der Init begonnen wird, andere Fuses, undefinierte
> Zugriffe,

Das kann gut sein, ich finde das momentan aber nicht.

foobar schrieb:
> Wenn man es in der Software nicht findet, ggfs mit dem Logic-Analyzer
> die komplette Init-Sequenz auf dem SPI-Bus vergleichen (inkl Timing!).

Init Vorgang an der SPI ist bei beiden FW's gleich.

Stefan ⛄ F. schrieb:
> Aber du könntest den Wiznet Chip direkt an deinen PC anschließen und
> diesen als DHCP Server verwenden. Dann hast du vollen Zugriff auf die
> Kommunikation.

Mein Wireshark ist mit einem Selbst gebastelten Adapter in die Leitung 
eingehangen. Ich sehe nur was zwischen PCB und Switch kommuniziert wird. 
mein PC kann da nichts mit rein senden.

Stefan ⛄ F. schrieb:
> Was ist, wenn der Chip mit der guten Firmware eine IP-Adresse aushandelt
> und danach mit der schlechten Firmware nur zuvor ausgehandelte IP
> Adressen nutzen kann?

Genau das ist mein Problem, deswegen habe ich diesen Fehler auch erst 
Monate Später beim bestücken von Leiterplatten entdeckt.

Stefan ⛄ F. schrieb:
> Wenn du den Chip auswechselst, dann hat der neue sicher eine andere (aus
> Sicht deines Routers jungfräuliche) MAC Adresse oder?

Die MAC Adresse bleibt in diesem Fall immer gleich, der Wiznet die MAC 
Adresse vom MCU bzw. der Firmware bekommt.

[Stefan F. (Gast)]

Moot S. schrieb:
> Mein Wireshark ist mit einem Selbst gebastelten Adapter in die Leitung
> eingehangen.

????

Dann kannst du doch nur die Hälfte (eine Richtung) der Kommunikation 
mitlesen. Geht das so überhaupt, ohne die Übertragung zu stören? Ich 
denke da an Stichleitungen und Wellenwiderstände.

[Moot S. (mootseeker)]

Stefan ⛄ F. schrieb:
> Dann kannst du doch nur die Hälfte (eine Richtung) der Kommunikation
> mitlesen.

Ja das Stimmt habe auf dem Adapter 2 Buchsen je für eine Richtung.

Hatte bis jetzt noch keine Probleme mit dem Adapter.
Den gleichen Adapter benutze ich auch auf der Arbeit zum Debuggen und 
Kommunikation analysieren.

[foobar (Gast)]

>> Wenn man es in der Software nicht findet, ggfs mit dem Logic-Analyzer
>> die komplette Init-Sequenz auf dem SPI-Bus vergleichen (inkl Timing!).
>
> Init Vorgang an der SPI ist bei beiden FW's gleich.

Wenn wirklich zur gleichen Zeit die gleichen Daten hin- und herlaufen 
(ein einfaches "sieht gleich aus" reicht nicht!), muss irgendein anderes 
Signal zum W5500 anders sein (Stromversorgung, Rst, PhyMode, ...) - 
schließlich kann das Teil nicht Gedanken lesen um zu wissen, ob es jetzt 
funktionieren soll oder nicht.

An sich sind reproduzierbare Fehler gut zu debuggen.  Häng Vcc, RST, SS, 
CLK, MISO, MOSI, INT an den Logic-Analyser.  Als erstes Takt und Flanken 
checken (richtige Speed, korrekter SPI-Modus?), dann die Daten 
dekodieren (beide Richtungen) und vergleichen.  Wenn immer noch nichts 
Auffälliges, Timing vergleichen, an dem die Kommandos abgesetzt werden.

Ach so: du benutzt hoffentlich nicht den Fixed-Length-Data-Mode (FDM)?

Wenn du einfach mal wild rumstochern möchtest, könntest du evtl mal die 
SPI-Geschwindigkeit ändern oder an strategischen Stellen einen Delay 
einsetzen.

Btw,
> die andere (LINK-LED) leuchtet oder blinkt garnicht.

In dem Fall brauchst du auch nicht auf Pakete warten ...