Hallo, nachdem wir nun das Problem mit der Konfiguration über EEPROM lösen konnten und einige Prototypen im Haus angekommen sind, haben wir nun folgendes Problem festgestellt: 2 von 5 Prototypen weisen einen Packetverlust von 30-35% auf. Die Zahl ergibt sich durch einfaches pingen von einigen Minuten bis hin zu mehreren Stunden (Der Durchschnitt liegt immer in diesem Bereich). Die Prototypen haben einen 5-fach Switch KSZ8895MQ ( http://www.micrel.com/_PDF/Ethernet/datasheets/ksz8895mq_rq_fmq_ds.pdf ) und wir verwenden das Prozessormodul VAR-SOM-OM37 von Variscite ( http://www.variscite.com/products/system-on-module-som/cortex-a8/var-som-om37-cpu-ti-am3703-dm3730 ). Bei 3 von 5 Prototypen kann ich vom PC aus das Prozessormodul ohne Paketverlust pingen und auch vom Prozessormodul aus hin zum PC. Des Weiteren hänge ich an einen weiteren Port ein Evaluationboard von Variscite mit einem anderen Prozessormodul (PM2) dran und pinge von dort aus, über den Prototypen dessen Modul oder den PC und umgekehrt. Somit habe ich folgende Wege: - PC -> Switch -> PM1 (auf dem Prototypen) - PM1 -> Switch -> PC - PC -> Switch -> PM2 (Evaluationboard) - PM2 -> Switch -> PC - PM1 -> Switch -> PM2 - PM2 -> Switch -> PM1 So. Bei zwei von 5 Prototypen habe ich in allen (!) Wegen einen Paketverlust. Nun habe ich versucht, über eine zweite Netzwerkkarte vom selben Rechner aus zu pingen: PC -> Switch -> PC und siehe da, kein Paketverlust feststellbar. Das selbe Phänomen tritt auf, wenn ich folgendes mache: PC -> Switch -> Evaluationboard für KSZ8895MQ -> PM2. Also wenn ich zwischen dem Switch und dem PM2 das Evaluationboard, das einen weiteren KSZ8895MQ enthält, dazwischen schalte, dann ist kein Paketverlust feststellbar. Deshalb habe ich nun mal damit begonnen, mich auf die Massen und die Schirmung genauer zu konzentrieren. Die Buchsen, die wir verwenden sind Magjack SI60062 F ( http://belfuse.com/pdfs/SI-60062-F.pdf ). Und ich habe auch versucht, die Massen von den Modulen zu verbinden usw., aber keine Besserung. Layouttechnisch befinden sich die Stützkondensatoren auf der Bottom-Seite der Platine sehr sehr sehr nahe den Pins (tlw. direkt dazwischen). Die Verbindung von Buchse BU1101 und BU1102 sind ca. 4 cm lang, von Buchse BU1103 ca. 13cm lang. Die Platine hat 6 Layer mit eigenem GND-Layer, wobei dieser aufgeteilt ist in GNDA und GNDD (Kopplung über einige Punkte). Die Datenleitungen befinden sich über dem GND-Layer und liegen nahe beieinander (parallel). Die Summensignale von TXP/TXM und RXP/RXM heben sich wunderbar auf, es sind keine Störspitzen erkennbar, die Massen sind auch überall sauber (keine Störspitzen mit Oszi erkennbar). Auch der Manchester-Code an sich sieht sehr gut und unauffällig bzgl. Störungen aus. Ansonsten befinden sich in dem Bereich von Ethernet auf der Platine keine weiteren HF-technischen Komponenten, nur Ethernet ;-) Die Konfiguration des Switch ist die Standardkonfiguration, sprich Port 5 sollte gleich wie die anderen 4 Ports beschaltbar sein. Außerdem stecke ich das selbe Prozessormodul in die anderen Prototypen und dort läuft es ja. Der Switch ist überall gleich konfiguriert. Was auch komisch ist: wenn ich bei den "funktionsfähigen" Prototypen an PMRXER (receive error) messe, dann ist dieser immer low. Bei den "nicht funktionsfähigen" Prototypen ist dort ein reger Wechsel (Stream?!) erkennbar. Bzgl. Schaltplan: nb bedeutet "nicht bestückt". Habe auch schon versucht 10pF Kondensatoren an die Datenleitungen zu hängen, um eventuelle hochfrequente Störspitzen zu filtern. Ich glaube, dass es sich um ein Hardwareproblem (oder auch ev. EMV-Problem) handelt, weiß aber leider nicht weiter. Bin auch noch nicht lange in dem Business ;-) Ist vielleicht nur eine Kleinigkeit, die ich einfach übersehe. Habt ihr schon Erfahrungen diesbezüglich machen können oder hat jemand eine Idee? Ich hoffe die Schaltpläne sind lesbar :-/ LG Silke
Aja die Jumper sind NICHT gesetzt! Habe auch versucht, Pin 2 und 5 der Buchsen über 100nF an Masse und Schirm zu hängen. LG Silke
Also wenn die Micrel Switche genausogut funktionieren wie die Etherner-Phys, dann wundert mich das nicht ;-). Musste gerade gaaanz schnell ein Design auf einen anderen (nicht-Micrel)Phy umgesignen, weil das Micrel Teil nicht funzt und der Hersteller keine Ahnung hat warum. Habt ihr ein Evalboard von dem IC? Damit würde ich vergleichen.
So habe mich nun registriert :-) AufArbeit schrieb: > Also wenn die Micrel Switche genausogut funktionieren wie die > Etherner-Phys, dann wundert mich das nicht ;-). > Musste gerade gaaanz schnell ein Design auf einen anderen > (nicht-Micrel)Phy umgesignen, weil das Micrel Teil nicht funzt und der > Hersteller keine Ahnung hat warum. Scheibenkleister :-/ Wir haben ein Evaluationboard von Micrel mit dem KSZ8895MQ (http://www.micrel.com/_PDF/?dir=Ethernet/hw_designkit/8895MQ_RQ) und halten uns eigentlich auch daran. Allerdings gibt es da schon ein paar Unterschiede: wir verwenden den Magjack, welcher die Transf. schon direkt enthält und auch die 75Ohm und den 1000pF/2kV. Micrel macht das alles separat mit dem Baustein H1664NL. Es sollte allerdings alles das Selbe sein, außer, dass die zwischen den CMG Pins noch jeweils 51Ohm vorgeschalten haben. Aber ich habe gemessen, ob die 100Ohm Abschlüsse bei uns vorhanden sind und die sind da :-/ Also zusammengefasst: Schaltungstechnisch sollte es das Selbe sein, hab dennoch versucht auf den CMG Leitungen noch nen Kondensator reinzupacken und mich noch mit den Abschlüssen gespielt - ohne Erfolg. Da gibt's übrigens noch ne application note von Micrel, die in dem obrigen Link enthalten ist. Da ist zu erkennen, dass die Datenleitungen direkt von Buchse zum Switch verbunden werden sollen und die CMG Pins offen bleiben sollen. Das zweite Evaluationboard ist jenes von Variscite für dessen Prozessormodul. http://www.variscite.com/products/system-on-module-som/cortex-a8/var-som-om37-cpu-ti-am3703-dm3730 da habe ich bis dato auch nichts Auffälliges gefunden und vergleiche es immer wieder. Aber wahrscheinlich übersehe ich einfach etwas :-( LG Silke
Netzwerker schrieb: > Halfduplex / Fullduplex Problem? Danke für den Tipp! Der Switch ist standardmäßig auf auto-negotiation eingestellt und sollte sich somit (soweit ich das verstanden habe) selbst half/full-duplex und speed suchen? Werde der Sache noch nachgehen! Warum ich allerdings so auf ein Hardware-Problem versteift bin ist, dass mit dem selben Prozessormodul und der selben Switch-Konfig die drei Prototypen einwandfrei spielen und halt die zwei nicht. Hmm. LG
Hi, Pin2+5 der MagJacks könnte man mal kapazitiv auf GND terminieren anstatt 3v3. C1115/6/7 ist für Störfestigkeit? pF eventuell geeigneter und abhängig von der Mechanik sollten die eher bei der Spannungsversorgung sein. Die (kapazitive)Verbindung GND - Shield sollte es wenn überhaupt nur einmal geben. Viel Erfolg, Gruß, Holger
Silke H. schrieb: > Danke für den Tipp! Der Switch ist standardmäßig auf auto-negotiation > eingestellt und sollte sich somit (soweit ich das verstanden habe) > selbst half/full-duplex und speed suchen? Da gehören zwei dazu. Es sollte auf beiden Seiten Autonegotiation funktionsfähig sein, eine Seite allein reicht nicht. Insbesondere nicht, wenn die andere Seite fest auf full duplex steht. Würde in der Entwicklung managed Switches empfehlen, mit ausführlicher Fehlerstatistik. Und auch testweise mal beide Seiten festlegen.
Wir hatten mal ein ähnliches Problem mit unerklärlichen Paketfehlern. Unser Problem hat sich dadurch gelöst, indem wir "bessere" 25 MHz Quarze verbauten.
Hallo, danke für eure Hilfe!! Ich werde die ganzen Tipps und Erfahrungen sofort ausprobieren! Echt ne tolle community! :-) A. K. schrieb: > Da gehören zwei dazu. Es sollte auf beiden Seiten Autonegotiation > funktionsfähig sein, eine Seite allein reicht nicht. Insbesondere nicht, > wenn die andere Seite fest auf full duplex steht. > > Würde in der Entwicklung managed Switches empfehlen, mit ausführlicher > Fehlerstatistik. Und auch testweise mal beide Seiten festlegen. Danke, die andere Seite liegt fest auf full-duplex 100Mb. Dann mach ich mich gleich mal ran :-) Holger schrieb: > Pin2+5 der MagJacks könnte man mal kapazitiv auf GND terminieren anstatt > 3v3. Vielen Dank, hatte ich bereits. Die kapazitive Verbindung von GND zu Shield werde ich nun gnadenlos rauswerfen :-) Habe sie jeweils direkt an den Buchsen dran. chester schrieb: > Unser Problem hat sich dadurch gelöst, indem wir "bessere" 25 MHz Quarze > verbauten. Wir verwenden diesen hier: http://www.digikey.com/product-detail/en/ECS-250-20-5PVX/XC1606CT-ND/1693775 Welchen verwendet ihr? LG Silke
Silke H. schrieb: > Wir verwenden diesen hier: > http://www.digikey.com/product-detail/en/ECS-250-2... > > Welchen verwendet ihr? Ich kann dir das nicht mehr genau sagen, da schon Jahre her, und ich damals an der SW gearbeitet habe. Aussehen: flach, gülden, und hatte 4 Anschlüsse, so wie das hier: http://i01.i.aliimg.com/wsphoto/v0/1115967627/Free-Shopping-20PCS-25MHz-25-000MHz-3-2x2-5-3225-passive-SMD-font-b-quartz-b.jpg
So. Habe nun den Switch auf 100Mb full-duplex konfiguriert und die Kondensatoren C1115-1117 entfernt. Pin 2 & 5 aller Buchsen sind mit 100nF auf Masse geschalten. Pin 8 aller Buchsen liegt auf Shield. Der Quarz lässt sich leider nicht so einfach ändern, die 25MHz sind allerdings sauber. Leider komme ich an dieser Stelle wieder nicht weiter, der Paketverlust ist immer noch vorhanden :-( Ich gehe grade nochmal das reference design vom Prozessormodul durch und schaue, ob die Massen und Versorgungen alle korrekt sind :-( Schönes WE! LG Silke
mach mal ne Direktverbindung ohne Switch. Kauf dir in der Bucht nen CISCO 29xx für ein paar Euronen. Der zeigt Dir dann auf allen Layern Probleme an. Das könnte helfen... hänge an deinen Switch mal zwei Linux dosen und pinge damit. Verändere mal die Paketgrößen. Suche systematisch nach Fehlern und nicht im Ganzen
Hallo!! Es läuft nun! Der Quarz benötigt noch einen ca. 33pF Kondensator zwischen seinem 1er Pin und dem Gehäuse ... Vielen Dank für eure Tipps!! LG Silke
> Es läuft nun! Der Quarz benötigt noch einen ca. 33pF Kondensator > zwischen seinem 1er Pin und dem Gehäuse ... Da sage noch einer Geduld zahlt sich nicht aus. Bussi aus M
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.