KSZ8851SNL Erfahrungen? Errata?

[Moesl0r (Gast)]

Grüß euch,

Ich implementiere momentan einen Micrel KSZ8851SNL Treiber auf einem 
xMega32e5 für den uIP Stack. Allerdings stehe ich momentan vor dem 
Problem, dass zuviele ICMP Packete verloren werden (~80%). Das Problem 
ist aufjedenfall im Treiber/der Hardware zu finden, da das verlorene 
Paket eben auch nicht am µC ankommt. Leider hab ich zu dem NIC auch 
keine Errata gefunden.

Nun meine konkrete Frage:
Gibt es bekannte Bugs bzw. nötige Workarounds für den NIC?
Gibt es kleine/grobe Mängel in der angehängten Schaltung?

[Knut B. (Firma: TravelRec.) (travelrec)]

Das einzige Erratum, was ich zu dem Chip kenne, ist bei der SNL-Version 
das Nichtfreigeben der MISO-Leitung, wenn /CS high ist. Dieser Fehler 
ist bei der SNL-I Version behoben. Ansonsten ist mir das Teil noch nie 
negativ aufgefallen, wir setzen es zu hunderten ein. Dein Schaltbild 
weicht insofern von den Herstellerempfehlungen ab, dass Du lediglich 
100nF Siebkondesatoren an den diversen Spannungspins angeschaltet hast, 
außer am 1.8V Ausgang. Original gehören da überall noch 10µF und 10nF 
parallel dazu. Vielleicht ist das die Ursache.

[Christian M. (moesl0r)]

Erstmal danke für die Antwort. Testweise hab ich die genanneten 10µF und 
die 10nF noch einmal dazu gelötet. Allerdings hat sich nichts geändert.

Dabei muss ich mich in dem Zuge gleich eine Aussage aus dem obigen Post 
korrigieren. Nicht 80% der Pakete gehen verloren, sondern 80% der Pakete 
gehen NICHT verloren.

[Gerd E. (robberknight)]

Ich würde das Teil jetzt an einen managebaren Switch anschließen, der 
mir in seiner Oberfläche Informationen zu der Verbindung (wie 
Übertragungsfehler etc.) bereitstellt. Dann auch mit einem 
Monitoring-Ausgang und Wireshark schauen was da wirklich für Pakete 
kommen.

[Christian M. (moesl0r)]

Das waren auch meine Ansätze zum Debuggen. Als switch habe ich einen 
smart managed Cisco switch verwendet, der mir auch anzeigt, dass auto 
negotiation funktioniert und sich der link im 100mbit full duplex modus 
befindet.

Während ein Paket auf der Empfangsseite "verloren" wird, wird auch das 
rx flag des NIC interrupt status reg nicht wie gewöhnlich gesetzt. Ich 
weiß einfach nicht mehr weiter.

Ich habe mal meine aktuell verwendeten Treiber Routinen angehängt. 
Vielleicht findet ja jemand etwas.

[Gerd E. (robberknight)]

Christian M. schrieb:
> Während ein Paket auf der Empfangsseite "verloren" wird, wird auch das
> rx flag des NIC interrupt status reg nicht wie gewöhnlich gesetzt. Ich
> weiß einfach nicht mehr weiter.

als erstes würde ich jetzt mal die MIB-Paketcounter von dem KSZ auslesen 
und schauen was sich da tut während ein paket verloren geht.

Dann vielleicht mal die verschiedenen Receive-Filter anschauen die man 
setzen kann.

[Moesl0r (Gast)]

YES! Ich habe den Fehler endlich gefunden. Zu meiner Schande muss ich 
gestehen, dass es sogar ein relativ offensichtlicher Konzept Fehler im 
Schaltplan ist.

So wie das Diodenarray "DALC208" im bereits gezeigten Schaltplan 
eingezeichnet ist, kann das natürlich nicht funktionieren. Im Fast 
Ethernet Betrieb sollten an der RX- bzw. TX- Leitung ca. -1V anliegen. 
Allerdings wird diese Spannung  durch die Dioden gegen GND auf -0,6V 
gedrückt. Soweit meine Analyse, die ich leider nicht mittels einer 
Messung bestätigen kann, aus Mangel an gutem Messwerkzeug.

Ein peinlicher Fehler, der jetzt kein Problem mehr darstellt. Auf das 
hab ich mir jetzt ein Bier gegönnt. Prost!