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.
Angehängte Dateien:
-
Wiznet_Schaltung.png
270 KB
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.
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
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.
Bei mir ging anfangs auch keine Kommunikation. Quarz raus, oszillator dran und schon ging alles. 73
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.
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.
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 :)
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
Ähm nein? ich brauche für meine Tests "frische" Chips. Das heisst welche die noch nie angesteuert wurden.
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
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.
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.
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
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!
Stefan ⛄ F. schrieb: > Laber doch keinen Schwachsinn! Keine Ahnung was früher so "gehandelt" wurde? Gehst zum Lachen auch in den Keller, wa?
Angehängte Dateien:
-
20210121_094259.jpg
240 KB -
20210121_094127.jpg
240 KB -
20210121_094121.jpg
240 KB -
20210121_094310.jpg
220 KB
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
20210121_231514.jpg
130 KB -
20210121_231529.jpg
230 KB
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.
:
Bearbeitet durch User
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 ^^
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
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.
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
Von den W5500 gab es unterschiedliche Revisionen. Wir hatten mit der älteren Revision auch mal Init-Probleme. Es gibt da irgendwo ein Errata zu.
Angehängte Dateien:
-
w5500.init.ohnekabel.png
88 KB -
w5500.init.ohnekabel.02.png
80 KB -
w5500.init.ohnekabel.03.png
87 KB -
w5500.init.ohnekabel.04.png
72 KB
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
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.
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
Und in der Herstellung wurden die natürlich auch nie getestet...
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.
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
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.
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
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.
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
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.
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.
Angehängte Dateien:
-
Bild1.png
22 KB
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?
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
:
Bearbeitet durch User
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?
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
:
Bearbeitet durch User
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.
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...
:
Bearbeitet durch User
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
:
Bearbeitet durch User
> 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 ...
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.
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).
>> 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.
> 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!).
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.
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?
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.
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.
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.
:
Bearbeitet durch User
>> 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 ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.