enc28j60 Probleme beim Enpfangen von Paketen

[Dennis K. (dennisk)]

Hallo alle zusammen,

folgendes Szenario:
- ATmega644A (16MHz Takt)
- enc28j60 (25MHz Takt)
- implementierte Protokolle: ARP
- netzwerk direkt zwischen PC und µC-Board
- wireshark auf PC zur Überwachung der Netzwerkdaten
- JTAGICE3

Das Senden von Paketen (ARP-Request) vom enc funktioniert einwandfrei, 
nur leider gibts Probleme beim Empfangen von Daten.
Zum Ablauf:
- Senden eines ARP-Requests von emc an PC (mit wireshark überprüft - 
alles ok)
- Antowrt des PC an emc (mit wireshark sieht die gesendete Antwort 
richtig aus)
- Lesen des Eingangspuffers im enc

Hierbei auftretende Fehler beim lesen des Eingangspuffers:
- die ersten 8 Byte der Nachricht fehlen (Dest. MAC) im Eingangspuffer - 
reproduzierbar, im Debugmodus anzusehen
 buffer[0] fängt mit source MAC an
- die Länge des empfangenen Pakets wird als ca. 6000 Bytes ausgelesen 
(laut wireshark ca. 50)

Ich habe schon verschiedene Sachen versucht, bin aber ziemlich ratlos 
woher dieser Fehler stammen könnte.

Meine enc_init und recvPaket Funktion habe ich angehängt. Diese habe ich 
teilweise aus demo-Projekten übernommen.

Ich hoffe mir kann jemand weiterhelfen.
MfG

[Jens (Gast)]

vielleicht mal unter:

http://www.ulrichradig.de/

avr webmodule oder webserver gucken....

JJ

[Dennis K. (dennisk)]

Ich habe mal einige Module von Ulrich Radig übernommen und angepasst, 
vorallem die ENCinit, die ENCwrite und ENCread Funktionen, aber leider 
keinen Erfolg gehabt.

Es sieht immernoch so aus, als ob der PC mir zu viele Daten schickt und 
damit meinen Puffer sprengt.

Wireshark zeigt zwar an, dass nur 42 Byte Daten gesendet werden, die 
Debugging Auswertung der Variable len in PacketRecieve zeigt höhere 
Werte.
Beim ersten Auslesen des Puffers sind es ungefähr 6000, beim zweiten 
schon 65000.

 Hat jemand eine Idee oder einen Ansatz?

[Uwe B. (derexponent)]

Hi Dennis,

> Beim ersten Auslesen des Puffers sind es ungefähr 6000, beim zweiten
> schon 65000.

der ENC28J60 hat nur einen internen Speicher von 8k Byte
(und das teilt sich nochmal in Receive und Sende Puffer)

ich vermute da stimmt Grundsätzlich was nicht

ein "normaler" ARP-Frame ist nur 64 Bytes lang
(Minus 14 Byte ETH-Header und 4 Bytes CRC gibt 46 Bytes Daten)

schau mal unter meiner Homepage :

www.Mikrocontroller-4U.de

da gibts einen fertigen minimal Treiber für einen ATMega2560
(musst du event. noch für den 644A anpassen)

ich hab aber nur ARP,ICMP und UDP implementiert

vlt hilft dir das als "Grundgerüst" weiter

Gruss Uwe

[Stefan (Gast)]

Ich habe mal irgendwo gelesen, dass der mAC Filter dieses Chips einen 
Bug hat und daher auch MAC Pakete für ganz andere Ziele irrtümlich im 
Empfangspuffer landen.

[Dennis K. (dennisk)]

Danke für die Antworten!

@Stefan: In diese Richtung habe ich auch schon gedacht.
Habe daraufhin einfach einmal das LAN-Kabel abgezogen nachdem eine Ping 
Nachricht vom PC an den enc28j60 gesendet wurde. Leider hat dies nichts 
geholfen.

@Uwe: Das da grundsätzlich etwas nicht stimmt hatte ich mir auch schon 
gedacht und das nur 8k Speicher zur Verfügung stehen ist mir auch klar.
Danke für das Beispiel, ich werde einmal sehen was ich damit anfangen 
kann.

MfG

[Dennis K. (dennisk)]

Ich habe den Fehler gefunden - endlich!!

Letzenendes war es ein sehr versteckter kleiner Fehler von mir in der 
Routine zum Auslesen des Empfangspuffers des ENCs.
Hatte ganz am Anfang einmal Probleme mit der Kommunikation zwischen ENC 
und µC weswegen ich da anscheinend eine kleine if-Bedingung 
auskommentiert hatte. Hierdurch wurde dann beim Lesen eines Bytes des 
Headers des Eingangspuffers immernoch ein dummy-Byte mitgesendet und 
dadurch zwei Byte ausgelesen.
Bei 6 Byte für next Packet Pointer und Status macht das insgesamt 12 
Byte, wodurch nachher die ersten 6 Byte der Nachricht fehlten - ganz 
davon abgesehen, dass der Inhalt des Status nicht gestimmt hat :-)

Nochmals danke an alle für die Hilfe!