Guten Abend zusammen, folgendes Szenario: - ATMega32 - ENC28J60 - Half/Full Duplex - 11,059 Mhz Takt bei ATMega - 25 MHz Takt bei ENC - ENC impl. Protokolle: IP, UDP, ICMP und ARP - pollingbetrieb zum Abfragen des ENC nach Packeten (derzeit alle 100ms) nun versuche ich eine Verbindung über einen Router Speedport W700V zu meinem Rechner herzustellen. Dies funktioniert auch grundsätzlich. Ich teste mit einem Ping Befehl der 100 Pings sendet. aus irgend einem Grund gehen im Full Duplex Mode ständig Pakete verloren (~14%) der Verlust folgt keinem Schema. Im Half Duplex Mode verliere ich genau jedes 4. Paket wobei auch der Link kurzzeitig aussetzt (laut LED). Was auch komisch ist, dass ich die LEDS eigentlich als receive und transmit eingestellt habe und nicht als link. Jedoch scheint LEDA wohl den Link status (zu erkennen beim Ziehen des Kabels). LED scheint richtig zu blinken. Wenn ich Rechner und ENC nur über einen Hub verbinde passiert das selbe und ich kann gut sehen das LEDB alle Pakete Signalisiert diese nur scheinbar nicht im Buffer abgelegt sind. LED Konfig: // sets LED configuration LEDA transmit activity, LEDB receive activity enc_writePhy(ENC_PHLCON,0x0120); Buffer Konfig: #define RX_BUF_START 0x0000 #define RX_BUF_END 0x19FF #define TX_BUF_START 0x1A00 #define TX_BUF_END 0x1FFF enc_writeReg(ENC_ERXSTL,ENC_BANK0,LO8(RX_BUF_START)); enc_writeReg(ENC_ERXSTH,ENC_BANK0,HI8(RX_BUF_START)); enc_writeReg(ENC_ERXNDL,ENC_BANK0,LO8(RX_BUF_END)); enc_writeReg(ENC_ERXNDH,ENC_BANK0,HI8(RX_BUF_END)); enc_writeReg(ENC_ETXSTL,ENC_BANK0,LO8(TX_BUF_START)); enc_writeReg(ENC_ETXSTH,ENC_BANK0,HI8(TX_BUF_START)); enc_writeReg(ENC_ETXNDL,ENC_BANK0,LO8(TX_BUF_END)); enc_writeReg(ENC_ETXNDH,ENC_BANK0,HI8(TX_BUF_END)); ich habe im Netz gelesen und auch hier das der ENC nicht perfekt ist.. aber ich denke irgendwas scheine ich noch falsch zu machen?!? Hoffe jemand hat einen spontane Idee um mir weiter zu helfen. Das Thema ist sehr interessant! Mfg und danke Tobi
Half Duplex kannst du beim ENC28J60 weitestgehend vergessen. Das ist nur mit viel Aufwand und vielen Kompromissen realisierbar. Full Duplex geht ganz gut, wenn man sich die Silicon Erratas zum ENC28J60 herunterlädt und die dort gegebenen Hinweise umsetzt. Jan und ich hatten für das Bootloader-Projekt damals die meisten dieser Fixes eingebaut und im Sourcecode dokumentiert. Du findest das Projekt unter http://code.google.com/p/avr-etherboot/source/checkout, für Dich ist die Datei enc28j60.c interessant.
HAllo andreas, Danke für deine antwort. Also dein Code hat mir schonmal geholfen. Jetzt kommen 95% durch würde och sagen. Der Rest sind alles timeout. Komisch ist nur dass manche der packete laut wireshark zurück kommen aber in der windows konsole trotzdem ein timeout kommt?!? Das verstehe ich nicht. Andere scheinen wirklich nicht beantwortet zu werden. Noch ne spontane idee Tobi
AChja... Kann es denn probleme geben wenn ich keinen ethernet überträger eingebaut habe? Habe eine rj45 buchse direkt mit den pins des enc verbunden.
Hallo, Tobi schrieb: > AChja... Kann es denn probleme geben wenn ich keinen ethernet überträger > eingebaut habe? Habe eine rj45 buchse direkt mit den pins des enc > verbunden. nö, die bauen alle anderen nur ein, weil sie weg müssen... Zumindest kann man sich so Probleme schaffen, die man vermutlich nicht hätte, wenn man sich an Datenblätter usw. hält. Mein Websever hat zumindest keine Pakete verloren, die Fehler, die ich am Anfang hatte, waren Softwarefehler und mit WireShark relativ gut zu erkennen. Gruß aus Berlin Michael
Hallo und danke für eure Antworten. Also ich hab mir jetzt ne MagJack reingebaut und siehe da es funktioniert.. allerdings nur wenn ich nebenher den Wireshark laufen habe Oo Wie kann das sein?? Mit Wireshark bekomme ich 100% Ping replays Ohne Wireshark nur den ersten Ping replay
Beitrag "ENC28J60 correct value of PHLCON and mirrored registers" > - pollingbetrieb zum Abfragen des ENC nach Packeten (derzeit alle 100ms) 100 ms ??
Zu half vs. full duplex: Wenn der Switch von der üblichen "dummen" Sorte ist (also kein gemanageter Switch), dann geht der bei einem Port so lange von half duplex aus, bis er mit dem drin steckenden Kollegen was anderes vereinbart hat (per auto negotiation). Da der ENC jedoch keine auto negotiation beherrscht bleibt der Switchport auf half duplex stehen. Wenn man den ENC nun auf full duplex stellt, dann wird das in die Hose gehen. Der ENC meint, er könne jederzeit senden, auch dann wenn er grad was empfängt. Der Switch sieht das freilich anders, hält es für eine Kollision und vernichtet beide Frames. Half duplex funktioniert nachweislich, ohne signifikantem Paketverlust. 600KB ohne Retry per UDP rausgeblasen kommt meistens komplett beim PC an.
Tobi schrieb: > allerdings nur wenn ich nebenher den Wireshark laufen habe Oo > Wie kann das sein?? Könnte dran liegen, dass der Wireshark den Adapter in den promiscuous mode versetzt (m.W. einstellbar), d.h. in einen Modus, in dem der Ethernet-Adapter alle Pakete empfängt. Normalerweise interessiert er sich nur für Broadcasts und die an ihn direkt adressierten Frames. M.a.W: Es könnte dran liegen, dass zwar die IP-Adressierung des Frames stimmt, nicht aber die MAC-Adressierung.
Andreas Vogt schrieb: > Half Duplex kannst du beim ENC28J60 weitestgehend vergessen. Das ist nur > mit viel Aufwand und vielen Kompromissen realisierbar. > Full Duplex geht ganz gut, wenn man sich die Silicon Erratas zum > ENC28J60 herunterlädt und die dort gegebenen Hinweise umsetzt. Datasheet: "The ENC28J60 does not support automatic duplex negotiation. If it is connected to an automatic duplex negotiation enabled network switch or Ethernet control- ler, the ENC28J60 will be detected as a half-duplex device. To communicate in Full-Duplex mode, the ENC28J60 and the remote node (switch, router or Ethernet controller) must be manually configured for full-duplex operation."
Initialisierung für half duplex:
1 | { MACON2, 0x00 }, // ?? |
2 | { MACON1, 0x0D }, // TXPAUS:1 RXPAUS:1 PASSALL:0 MARXEN:1 |
3 | { MACON3, 0x32 }, // pad small frames, check frame length, half duplex |
4 | { MAIPGL, 0x12 }, |
5 | { MAIPGH, 0x0C }, |
6 | |
7 | ephy_write(PHCON1, 0x0000); // half duplex |
8 | ephy_write(PHCON2, 0x0100); // half duplex loopback disable (see errata) |
HAllo... Erstmal danke für eure beiträge! Das mit der falschen mac adresse kann doch nicht sein da dieses problem erst auftritt seit ich die magjack angeschlossen habe?! Ich werde dies jedoch morgen nochmals überprüfen. Das mit dem full und half duplex werde ich morgen auch mal umschalten. Hab das im code eh schon über defines vorgesehen. Wegen den 100ms....dies ist klar recht langsam...sollte aber für erste nachvollziehbare tests ohne probleme ausreichen. Grusse tobi
oh man, stimmt die destination MAC war die selbe wie die Source... da hab ich wohl ned aufgepasst. Nur wundert es mich das es mit der normalen RJ45 Dose ohne Überträger sporadisch ging.. naja. nun habe ich einen Hardcore ping test durchgeführt. Resultat: 1000 gesendet 7 verloren.... hm... eigentlich sollte doch alles durch gehen. Das Ganze im Full Duplex Komisch ist auch, dass die LEDs nicht angesteuert werden. Hab eine auf receive und eine auf transmit gestellt. jedoch blinkt die transmit auch nur sporadisch. Kann es sein dass normale LEDs die ich gerade im Aufbau dran hab nicht getrieben werden können von der Last?!?
Tobi schrieb: > Resultat: 1000 gesendet 7 verloren.... hm... eigentlich sollte doch > alles durch gehen. Das Ganze im Full Duplex Eine Konfiguration mit FDX-Device und HDX-Switchport kann immer mal zu Frameverlusten führen, abhängig vom exakten Ablauf der Datenübertragung, der Häufigkeit von Broadcasts beliebiger Stationen im LAN und evtl. auch vom Typ des Switch. Das kann sich mit etwas Glück kaum nennenswert auswirken, oder gering wie bei dir, oder auch massiv. Gewisse Probleme des real existiernden ENC28J60 (=> Errata) können allerdings auch im HDX-Modus zu leichten Problemen führen, aber beispielsweise die bzgl. excessive collisions sind mit Switch am anderen Ende eher unwahrscheinlich (Hardware/Kabel/Portdefekte mal aussen vor gelassen). Bleiben hauptsächlich die möglichen drops durch den presence pulse - das ist dann schlicht Pech und man muss damit leben. In meinem Fall ist mir das freilich noch nicht unangenehm aufgefallen. Generell sollte dein Gerät damit leben können, dass Pakete in geringem Umfang wie über die Wupper gehen. TCP kann das ohnehin.
hallo zusammen, hab es nun nicht mehr besser hin bekommen. Aber ist schon wahr, TCP regelt das und mit diesem Verlust kann man leben. Nun versuche ich DHCP zu implementieren. Irgendwie habe ich das Problem, dass im Wireshark rein gar nichts ankommt. Nicht einmal der Discover der direkt zu Beginn gesendet werden müsste. Bis zu welcher Ebene muss eigentlich ein Ethernet Packet richtig sein damit ich es im Wireshark schonmal sehen könnte ohne das es der Router wohl verwirft? Ich denke wenn z.b. der Datenteil im UDP falsch wäre würde das Packet doch trotzdem ins Netz gesendet werden?!? Ansonsten vermute ich das der ENC es blockieren könnte.. jedoch fällt mir da auch nur die MAC des Source ein die falsch sein könnte damit er es ned sendet. Jedoch ahbe ich dies schon ausgeschlossen. Jemand ne spontane Idee was ich überprüfen könnte? Mfg Tobi
Tobi schrieb: > Bis zu welcher Ebene muss eigentlich ein Ethernet Packet richtig sein > damit ich es im Wireshark schonmal sehen könnte ohne das es der Router > wohl verwirft? Wireshark zeigt alle Pakete an die an der Schnittstelle ankommen > Ich denke wenn z.b. der Datenteil im UDP falsch wäre würde das Packet > doch trotzdem ins Netz gesendet werden?!? ja > Ansonsten vermute ich das der ENC es blockieren könnte.. jedoch fällt > mir da auch nur die MAC des Source ein die falsch sein könnte damit er > es ned sendet. Jedoch ahbe ich dies schon ausgeschlossen. der gibt auch alles raus > Jemand ne spontane Idee was ich überprüfen könnte? verbinde den Server per Kabel direkt mit dem Rechner auf dem Wireshark läuft Sascha
ok.. also ich habe die Rechner nun über einen Hub miteinander verbunden. geht auch nicht. Komisch ist, dass ich jetzt sogar einmal einen Hex Stream selber zusammengebastelt habe und in direkt sende. Einen DHCP Discover und einen ARP (beide abgeschaut von Paketen mit einem normalen Rechner und agepasst) unsigned char discover[342] ={0xff ,0xff ,0xff ,0xff ,0xff ,0xff ,0x00 ,0x22 ,0xF9 ,0x02 ,0x1D ,0x55 ,0x08 ,0x00 ,0x45 ,0x00 ,0x01 ,0x48 ,0x31 ,0xcf ,0x00 ,0x00 ,0x80 ,0x11 ,0x07 ,0xd7 ,0x00 ,0x00 ,0x00 ,0x00 ,0xff ,0xff ,0xff ,0xff ,0x00 ,0x44 ,0x00 ,0x43 ,0x01 ,0x34 ,0x01 ,0x45 ,0x01 ,0x01 ,0x06 ,0x00 ,0x89 ,0x43 ,0x9b ,0x8c ,0x0d ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x22 ,0xF9 ,0x02 ,0x1D ,0x55 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x63 ,0x82 ,0x53 ,0x63 ,0x35 ,0x01 ,0x01 ,0x3d ,0x07 ,0x01 ,0x00 ,0x22 ,0xF9 ,0x02 ,0x1D ,0x55 ,0x32 ,0x04 ,0xc0 ,0xa8 ,0x02 ,0x69 ,0x0c ,0x0a ,0x46 ,0x61 ,0x6d ,0x69 ,0x6c ,0x69 ,0x65 ,0x2d ,0x50 ,0x44 ,0x3c ,0x08 ,0x4d ,0x53 ,0x46 ,0x54 ,0x20 ,0x35 ,0x2e ,0x30 ,0x37 ,0x0c ,0x01 ,0x0f ,0x03 ,0x06 ,0x2c ,0x2e ,0x2f ,0x1f ,0x21 ,0x79 ,0xf9 ,0x2b ,0xff ,0x00 ,0x00 ,0x00 ,0x00 ,0x00}; ethSendFrame(discover, 342); unsigned char arp[42] ={0xff ,0xff ,0xff ,0xff ,0xff ,0xff ,0x00 ,0x22 ,0xF9 ,0x02 ,0x1D ,0x55 ,0x08 ,0x06 ,0x00 ,0x01 ,0x08 ,0x00 ,0x06 ,0x04 ,0x00 ,0x01 ,0x00 ,0x22 ,0xF9 ,0x02 ,0x1D ,0x55 ,0xc0 ,0xa8 ,0x02 ,0x09 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0xc0 ,0xa8 ,0x02 ,0x64}; ethSendFrame(arp, 42); .. falls es jemanden inetressiert. Aber bei beiden zeigt der Wireshark keine Regung. Komisch ist nun aber, dass wenn ich einen Ping bekomme dieser beantwortet werden kann und auch im Wireshark dies eindeutig nachvollziehbar ist. Der Pong endet im AVR Code ebenfalls in der Funktion ethSendFrame... wieso funktioniert nur der Pong und sonst nichts anderes das ich in ein Ethernet Packet stecke? Hab ich was grundsätzliches vergessen evtl? Mfg Tobi
hub oder switch? hast du im Wireshark den 'promiscuous mode' aktiviert? Sascha
also ich hab unter Capture - Options - Capture packets in promiscuous mode ein häckchen drin.. denke das wird das sein... schade.. wäre mir auch recht gewesen wenn das alles gewesen wäre..
* wie sendest du die Pakete? per Taster ausgelöst oder nach dem Reset 1x?? * was sagt die Tx/Rx-LED am ENC - gehen Daten raus? Sascha
also ich hab mir nen pin als input konfiguriert welcher zu beginn den Startimpuls gibt. Wegen den LEDs... da hab ich auch noch ein Problem.. hab eigentlich eine als TX und eine als RX konfiguriert... hab 2 ganz normale LEDs dran gegen 5V im Full Duplex... leider blinken die irgendwie gar nicht. Nach dem Init des ENC gehen beide aus.
jetzt hatet ich ein komisches verhalten... ich habe nach der ENC initialisierung einen delay von 100ms eingebaut und dann kam manchmal der DHCP und der UDP durch... Ich vermute ich habe ein Grundproblem mit der SPI. Dort habe ich ein display dran und eben den ENC.. Eigentlich schalte ich immer sauber um.. aber kann es da irgendwelche Probleme geben wenn ich diese beide sozusagen parallel am SPI port habe? Mfg Tobi
nun vermute ich langsam ein Hardwareproblem. Ich denke ich habe meistens den Link status nicht abgewartet. Wenn ich nun auf den Link warte, dann erhalte ich Pakete. Nur witzigerweise kommt meist nur der ARP durch den ich Hard gecoded habe. Wenn ich die Stromversorgung länger aus lasse und dann einschalte, auf den Link warte, dann kommt nur der DHCP durch. Wenn ich dann wieder schnell nacheinander aus und einschalte, auf den Link warte, dann kommt immer nur der ARP durch... wie kann das sein in einem sequentielen Code??? Jemand ne Idee was da hardwareseitig sein könnte? SPI ist direkt verbunden ohne R und ohne C. Mfg Tobi
also irgendwie verstehe ich das nicht mehr... die DHCP und die ARP kommen nie gleichzeitig was sie eigentlich sollten. und es kommt nur wenn dann eine der beiden. Die DHCP kommt irgendwie wenn dann immer 2 mal direkt nacheinander... ok macht vielleicht der router?!? Und warum die Link LED nun zwar den Link status anzeigt jedoch ab und zu auch meint sie müsste blinken?!? Ich evrstehe es nicht mehr... (enc_writePhy(ENC_PHLCON,0x0420)) Vielleicht jemand ne Idee? hoff Mfg Tobi
wie sieht deine INIT des ENC aus? Hab mal meine ENC_Routinen angehangen, ist zwar ASM aber der originale C-Code steht noch dazwischen (ist aus dem Projekt von U.Radig). Nach dem INIT des ENC und anschließen des Netzwerkkabels dauerts schon noch etwas bis der Link steht was du davor zu senden versuchst geht sicher verloren. Die Broadcasts ARP und DHCP sollten eigentlich immer durch einen Switch gehen. An sonsten nur ENC und Rechner mit Kabel verbinden. Sascha
also mein init sieht so aus:
1 | uint8_t init_ENC(){ |
2 | |
3 | reset_ENC(); |
4 | |
5 | // wait for the CLKRDY bit
|
6 | while((enc_readReg(ENC_ESTAT, enc_cur_bank, 1) & 0x01) != 0x01); |
7 | |
8 | // ENC28J60 Rev. B7 Silicon Errata workaround #1, ESTAT.CLKRDY is not working
|
9 | _delay_ms(1); |
10 | |
11 | // sets Buffer RX/TX start/ end pointer
|
12 | enc_writeReg(ENC_ERXSTL,ENC_BANK0,LO8(RX_BUF_START)); |
13 | enc_writeReg(ENC_ERXSTH,ENC_BANK0,HI8(RX_BUF_START)); |
14 | enc_writeReg(ENC_ERXNDL,ENC_BANK0,LO8(RX_BUF_END)); |
15 | enc_writeReg(ENC_ERXNDH,ENC_BANK0,HI8(RX_BUF_END)); |
16 | enc_writeReg(ENC_ETXSTL,ENC_BANK0,LO8(TX_BUF_START)); |
17 | enc_writeReg(ENC_ETXSTH,ENC_BANK0,HI8(TX_BUF_START)); |
18 | enc_writeReg(ENC_ETXNDL,ENC_BANK0,LO8(TX_BUF_END)); |
19 | enc_writeReg(ENC_ETXNDH,ENC_BANK0,HI8(TX_BUF_END)); |
20 | |
21 | // sets MARXEN, TXPAUS, RXPAUS
|
22 | enc_writeReg(ENC_MACON1,ENC_BANK2,0x0D); |
23 | |
24 | // sets PADCFG0, ENC_BIT_TXCRCEN, ENC_BIT_FRMLNEN, ENC_BIT_FULDPX
|
25 | #ifdef HALF_DUPLEX
|
26 | enc_writeReg(ENC_MACON3,ENC_BANK2,0x32); |
27 | #else
|
28 | enc_writeReg(ENC_MACON3,ENC_BANK2,0x33); |
29 | #endif
|
30 | |
31 | // sets MACON4 IEEE 802.3 conformance
|
32 | enc_writeReg(ENC_MACON4,ENC_BANK2,0x40); |
33 | |
34 | // sets MAMXFLL and MAMXFLH for maximum 1518 frames 0x05EE
|
35 | enc_writeReg(ENC_MAMXFLL,ENC_BANK2,0xEE); |
36 | enc_writeReg(ENC_MAMXFLH,ENC_BANK2,0x05); |
37 | |
38 | // sets MABBIPG Back to Back inter packet gap
|
39 | #ifdef HALF_DUPLEX
|
40 | enc_writeReg(ENC_MABBIPG,ENC_BANK2,0x12); |
41 | #else
|
42 | enc_writeReg(ENC_MABBIPG,ENC_BANK2,0x15); |
43 | #endif
|
44 | |
45 | // sets MAIPGL Back to Back inter packet gap
|
46 | enc_writeReg(ENC_MAIPGL,ENC_BANK2,0x12); |
47 | #ifdef HALF_DUPLEX
|
48 | enc_writeReg(ENC_MAIPGH,ENC_BANK2,0x0C); |
49 | #endif
|
50 | |
51 | // sets MAC Adress
|
52 | enc_writeReg(ENC_MAADR0,ENC_BANK3,MAC6); |
53 | enc_writeReg(ENC_MAADR1,ENC_BANK3,MAC5); |
54 | enc_writeReg(ENC_MAADR2,ENC_BANK3,MAC4); |
55 | enc_writeReg(ENC_MAADR3,ENC_BANK3,MAC3); |
56 | enc_writeReg(ENC_MAADR4,ENC_BANK3,MAC2); |
57 | enc_writeReg(ENC_MAADR5,ENC_BANK3,MAC1); |
58 | |
59 | // CLOCK OUT OFF
|
60 | enc_writeReg(ENC_ECOCON,ENC_BANK3,0x00); |
61 | |
62 | // sets PYH Reg PHCON1 PDPXMD for full duplex
|
63 | #ifdef HALF_DUPLEX
|
64 | enc_writePhy(ENC_PHCON1,0x0000); |
65 | #else
|
66 | enc_writePhy(ENC_PHCON1,0x0100); |
67 | #endif
|
68 | |
69 | // sets PYH Reg PHCON2 HDLDIS for half duplex to prevent auto loopback
|
70 | #ifdef HALF_DUPLEX
|
71 | enc_writePhy(ENC_PHCON2,0x0100); |
72 | #endif
|
73 | |
74 | |
75 | // sets LED configuration LEDA transmit activity, LEDB receive activity
|
76 | // enc_writePhy(ENC_PHLCON,0x3121);
|
77 | enc_writePhy(ENC_PHLCON,0x0420); |
78 | |
79 | // set first rx buffer location to rx buffer start adress
|
80 | enc_next_rxPacketPtr = RX_BUF_START; |
81 | |
82 | // enable interrutps
|
83 | enc_writeReg(ENC_EIE,enc_cur_bank,0xC0); |
84 | |
85 | // disable all filters
|
86 | enc_writeReg(ENC_ERXFCON,ENC_BANK1,0x00); |
87 | |
88 | // enable receive
|
89 | enc_setRegBits(ENC_ECON1,0x04); |
90 | |
91 | return 1; |
92 | }
|
93 | |
94 | void reset_ENC(){ |
95 | enable_LAN(); |
96 | spi_put(0xFF); |
97 | disable_All(); |
98 | }
|
Tobi schrieb: > void reset_ENC(){ > enable_LAN(); > spi_put(0xFF); > disable_All(); > } Ich weiß nicht, was enable_LAN() und disable_All() bei Dir macht, aber bei uns sah der Reset des Enc so aus:
1 | ENC28J60_CONTROL_DDR |= (1<<ENC28J60_PIN_CS); |
2 | ENC28J60_CONTROL_PORT |= (1<<ENC28J60_PIN_CS); |
3 | |
4 | for (i=0;i<30;i++) |
5 | _delay_ms(35); |
6 | |
7 | // perform system reset
|
8 | enc28j60WriteOp(ENC28J60_SOFT_RESET, 0, ENC28J60_SOFT_RESET); |
9 | |
10 | for (i=0;i<30;i++) |
11 | _delay_ms(35); |
Soweit ich mich erinnere, waren die beiden delay-Schleifen wichtig. Wenn man sie wegließ oder verkürzte, funktionierte der Enc nicht richtig. Versuch das doch mal.
... ein geniales Forum mit genialen Leuten... ES FUNKTIONIERT!!!! unglaublich. Da wäre ich ja nie drauf gekommen. Jetzt wird wie erwartet zuerst das DHCP Paket und danach das ARP Paket gesendet. Jetzt muss ich noch rausfinden ob wirklich so lange Wartezeiten notwendig sind jeweils?!? Schade das das nicht in der Spec steht.. vielleicht hab ich das auch übersehen.. werd ich gleich nochmal prüfen. DANKE EUCH!!!!
ich hatte nun zwischen den beiden Paketen einen delay von 200ms eingebaut. sende ich sie nun ohne den delay, wird nur das erste (das DHCP) gesendet. Komischerweise warte ich eigentlich im sende Teil des Enc max. 100ms bis der vorherige Transmit abgeschlossen ist. Wie kann das sein das es trotzdem nicht gesendet wird? Wie sind eure Erfahrungen mit dem Senden mehrerer Pakete nacheinander und entsprechenden Wartezeiten? Mein Enc Code für tx:
1 | void enc_txPacket(unsigned char *buf, unsigned int len) |
2 | {
|
3 | unsigned char controlbyte = 0; |
4 | unsigned int ms = 1000; |
5 | |
6 | |
7 | // ENC28J60 Rev. B7 Silicon Errata workaround #10,
|
8 | // Internal transmit logic may stall in half duplex mode
|
9 | // on excessive collisions, a late collision or excessive deferrals
|
10 | // In this case the Transmit Error Interrupt Flag is set. Check it
|
11 | #ifdef HALF_DUPLEX
|
12 | if(!(enc_readReg(ENC_EIR,enc_cur_bank,1) & 0x02)) |
13 | { // Reset transmit logic |
14 | enc_setRegBits(ENC_ECON1,0x80); |
15 | enc_clrRegBits(ENC_ECON1,0x80); |
16 | enc_clrRegBits(ENC_EIR, 0x02); |
17 | }
|
18 | #endif
|
19 | |
20 | // wait up to 100 ms for the previous tx to finish
|
21 | while( ms-- ) { |
22 | if(!(enc_readReg(ENC_ECON1,enc_cur_bank,0) & 0x08)) break; |
23 | _delay_us(100); |
24 | }
|
25 | |
26 | // reset tx logic if TXRTS bit is still on
|
27 | #ifdef HALF_DUPLEX
|
28 | if(1){ |
29 | #else
|
30 | if((enc_readReg(ENC_ECON1,enc_cur_bank,0) & 0x08)){ |
31 | #endif
|
32 | enc_setRegBits(ENC_ECON1,0x80); |
33 | enc_clrRegBits(ENC_ECON1,0x80); |
34 | }
|
35 | |
36 | // set start pointer in buffer
|
37 | enc_writeReg(ENC_EWRPTL,ENC_BANK0,LO8(TX_BUF_START)); |
38 | enc_writeReg(ENC_EWRPTH,ENC_BANK0,HI8(TX_BUF_START)); |
39 | |
40 | // set end pointer in buffer
|
41 | enc_writeReg(ENC_ETXNDL,ENC_BANK0,LO8(TX_BUF_START+len)); |
42 | enc_writeReg(ENC_ETXNDH,ENC_BANK0,HI8(TX_BUF_START+len)); |
43 | |
44 | // add control byte
|
45 | enc_writeBuf(&controlbyte,1); |
46 | |
47 | // set header and data to buffer
|
48 | enc_writeBuf(buf,len); |
49 | |
50 | // clear TXIF flag
|
51 | enc_clrRegBits(ENC_EIR,0x08); |
52 | |
53 | // start transmission by setting the TXRTS bit
|
54 | enc_setRegBits(ENC_ECON1,0x08); |
55 | |
56 | }
|
Guten Tag zusammen, also der DHCP Discover eht nun zuverlässig raus. JUHU irgendwie antwortet der Router allerdings nicht. Komischerweise sendet er nur ein paar ARPs mit der Frage wer die erste IP adresse hat aus seinem DHCP Adress Pool. Mehr passiert nicht.. aber eigentlich sollte er doch einfach einen Offer senden?!? Oder hab ich da was falsch verstanden? Jemand vielleicht noch ne Idee zu vorhergehendem Problem das ich keine Pakete scheinbar direkt hintereinander senden kann? Danke Grüsse Tobi
Sorry für die vielleicht blöde Frage, aber wieso schaust du dir nicht den Source eines Projektes an, wo DHCP zuverlässig funktioniert?
Guten Abend, ich hab ja ein Referenzproejkt... und es funktioniert ja auch soweit alles.. ich denke eher das es sich hier um eine NEtzwerkthematik handelt hinter die ich nicht ganz komme. Mein Handy sendet z.b. immer mal wieder einen DHCP Request und auch da sehe ich im Wireshark keine Antwort des Routers. Scheinbar verstehe ich da irgendwas falsch und komme einfach nicht drauf. Ich filtere auf bootp. Allerdings ohne Filter kommt auch ned viel sinnvolles. Es kommen dann nur ARPs oder DHCPv6 Nachrichten wobei ich nicht glaube das die was direkt damit zu tun haben. Müsste nicht nach einem Discover ein Offer kommen? Und das bei allen Routern?!? Mfg Tobi
also ich habe nun herausgefunden, dass ein DHCP Offer wohl gesendet wird. Ich habe nur bei der Abfrage im UDP PAcket Source und Dest Port vertauscht so das keine weitere Auswertung statt fand. Nur komisch ist, dass dieses Offer nicht im Wireshark angezeigt wird?!? Ich hatte daraufhin auch zuerst noch ein fehlerhaftes DHCP Request Paket gesendet. Dies habe ich dann gesehen und auch das DHCP NAK vom Router. Nun geht zwar technisch alles nur wird das DHCP ACK das ich sehen sollte im Wireshark ebenfalls nicht angezeigt. Wie kann das sein?!?! Das muss dich an einer Einstellungen liegen oder liegt das am Netzwerk selbst? Ich kann alle DHCP Nachrichten sehen ausser DHCP OFFER und ACK. Hoffe auf eine aufschlussreiche Antwort, da mich das brennend interessiert und ich es mir nicht erklären kann. Mfg Tobi
Hallo, Du hast nichts geschrieben, wie Dein Filter im Wireshark aussieht. Ohne Filter siehst Du alle DHCP Pakete, die von/zu dem Rechner geschickt werden, auf dessen Netzwerkkarte der Wireshark horcht. Hast Du Deine Hardware mit ENC28J60 in einem MiniSwitch, der evt. gleich noch mit im Router eingebaut ist und der Router ist der DHCP Server und der PC mit Wireshark steckt an einem der anderen Ports des im Router eingebauten MiniSwitches (also wie zum Beispiel ein Speedport der Telekom / AVM Fritzbox mit 4 LAN Ports), dann siehst Du die Antwort vom Router nicht mehr unbedingt. Wenn Du die auch sehen willst, mußt Du PC+ENC28J60 in einen HUB stecken oder Du brauchst einen Switch, der Port Spiegelung kann. Zum Beispiel einen alten 3COM3300 (ca. 10 Euro+Versand bei ebay). Da kannst Du dann dann z.B. den ENC28J60 Port Spiegeln zu einem "Monitor" Port wo Dein PC drin steckt. Dann siehst Du mit dem Wireshark alle Pakete, die aus dem ENC28J60 hinein/hinaus geschickt werden (und die von Deinem PC selbst). Richtige Konfiguration des 3300 vorausgesetzt. Viele Grüße und Erfolg Netzwerker
Hallo Netzwerker, danke für deine Antwort. Also ich habe ENC und PC an einem Speedport... genau dein Beispiel :) Laut deiner Aussage sehe ich dann die Pakete nicht unbedingt.. ok scheint wirklich so zu sein.. kannst du mir auch erklären wieso? Lösung wäre also einen Hub.. und dort Router, ENC und PC dran oder funktioniert das noch nicht so? Hub hätte ich noch einen da. Mfg Tobi
Ein Switch weiss welche MAC-Adressen an welchem Port zu finden sind. Alles was also kein Broadcast ist, wird er nur dorthin leiten, wo der Empfänger sitzt. Deswegen sieht dein PC nicht die Pakete die direkt zwischen ENC28J60 und Router ausgetauscht werden. Dein Vorschlag mit den Hub müsste so funktionierne, oder ein managebarer Switch bei dem man einen Port auf "Monitor" schalten kann.
Hallo, wenn Du einen echten schönen alten HUB Dein Eigen nennen kannst, stöpsele das um (für die Fehlersuche) -> alles in den HUB. Wenn das mit HDX/FDX funktioniert, müßtest Du alle Pakete sehen. Wenn Dein PC ein Windows System ist, und der die IP vom Speedport per DHCP bekommt, dann starte mal den Sharki. Mach mal eine DOS Box auf (Ausführen cmd) und da ipconfig /renew. Dann solltest Du die DHCP Pakete von Deinem PC sehen können wie Du die erwartest (siehe oben). Ja und dann das mit dem ENC28J60. Das muß dann ebenso aussehen. Ich mach das jeden Tag und habe für Fehlersuche auch so einen kleinen uralten MINIHUB auf meinem Schreibtisch. Viele Grüße und Erfolg Netzwerker
Hallo Und danke für eure antworten, Das mir dem hub funktioniert einwandfrei. Jetzt sehe ich wirklich alles :) Also falls jemand ein ähnliches problem hat, einfach mal nen hub dran dann kann man sicher sein man sieht alles was auf dem netzwerk passiert. Danke euch!! Tobi
Schön für Dich, ich frage mich allerdings, warum dich am 05.03.2011 00:13 mir die Mühe machte, einen Beitrag zu schreiben, wenn Du hier > // enc_writePhy(ENC_PHLCON,0x3121); > enc_writePhy(ENC_PHLCON,0x0420); es wieder nicht beachtest, dass das oberste Nibble nicht 0, sondern 3 sein muss.
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.