Hallo ! konnte zwar mein Problem mit dem Hardware SPI ( http://www.mikrocontroller.net/forum/read-1-309359.html#309359 ) noch nicht lösen, aber mit der softwaremässigen Implentierung scheint es halbwegs zu klappen. Hab jetzt aber wieder das nächste Problem: Die Daten die vom ENC empfangen und gesendet werden sind fehlerhaft und stimmen nicht mit den von Ethereal aufgezeichneten überein. Als Beispiel: ARP Broadcast vom Computer an 192.168.0.20 PC (Etherreal): 0000 ff ff ff ff ff ff 00 11 d8 5e e0 2e 08 06 00 01 ........ .^...... 0010 08 00 06 04 00 01 00 11 d8 5e e0 2e c0 a8 00 01 ........ .^...... 0020 00 00 00 00 00 00 c0 a8 00 14 ........ .. Emfpang beim ENC: rxstat: 0x0 len: 0x70 Received packet len: 112, type:0x21 | 33 Packet Contents 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF ----------------------------------------------- ---- ASCII ----- 0000 FF FF FF FF F0 02 76 2F E0 5C 20 30 00 21 00 03 ÿÿÿÿð.v/à\ 0.!.. 0010 04 00 04 00 1D 0B B8 17 C0 50 00 08 00 00 00 00 ......¸.ÀP...... 0020 00 81 A0 00 40 00 00 00 00 00 00 00 00 00 00 00 . .@........... 0030 00 00 00 00 0B 1E 92 A7 B D.h. schon die Länge stimmt nicht mit dem gesendeten überein, und bei den Daten scheinen nur die ersten paar Bytes richtig zu sein (sofern man das mit 0xFF beurteilen kann ;) ) Ähnliches spielt sich beim Senden ab: ENC sendet ein UDP Packet an 255.255.255.255:4950 mit dem Inhalt "hello_test". Ethereal erhält: 0000 ff ff ff ff ff ff 66 55 44 33 22 11 08 00 59 00 ......fU D3"...Y. 0010 00 4e 00 00 00 00 80 11 f3 fc c0 a8 00 14 ff ff .N...... ........ 0020 ff ff 13 56 13 56 00 3a 00 00 bc 23 ff 90 b9 8a ...V.V.: ...#.... 0030 fa f1 07 1d 93 f3 48 89 c6 26 0b c7 a3 e2 b7 b2 ......H. .&...... 0040 07 a4 a1 33 73 4e f0 3c a4 e7 3a 7c 2e 53 3e a1 ...3sN.< ..:|.S>. 0050 e8 ff 1f b0 da d4 b3 00 00 00 00 00 ........ .... Hierbei sind dann aber die Source IP (192.168.0.20) und die MAC vom ENC (665544332211) richtig. Nur der Rest der Daten ist wieder irgendwas... Der Speicher vom ENC an sich dürfte keine Probleme machen; zumindest zeigt der Speichertest (übernommen vom Microchip Stack) daß alles in Ordnung ist. Die grundsätzlichen Routinen hab ich von der avrlib übernommen und an soweit notwendig an meinen Controller (M16C) angepasst. Was mir noch auffällt: Wenn ich das Bit LLSTAT vom PHSTAT1 Register abfrage, erhalte ich die Antwort, daß der MAC Layer nicht verbunden ist. Auch die Link Led leuchtet am ENC nicht; am Switch hingegen schon. Die LED selber funktioniert aber. Und noch etwas was mich interessiert: Was hat es mit dem Lesen der MAC und MII Register auf sich; diese beginnen ja laut Datenblatt alle mit MAC bzw MI und sind mit einem speziellen Lesebefehl zu behandeln, bei dem erst ein Dummy Byte ausgelesen wird und erst danach das eigentliche Datenbyte. Aber in der AVRLib wird auch für dir MAC Register der normale Lesebefehl wie für die anderen Register benutzt; auch praktisch funktioniert bei mir nur dieser. Hab ich da in der Errata Note etwas dazu übersehen ? Oder verstehe ich da irgendwas im Datenblatt falsch ? Hat jemand ne Ahnung was ich da bei der Fehlersuche noch überprüfen könnte ? Mir fällt langsam nichts mehr ein. Schöne Grüße, Thomas B.
>Aber in der AVRLib wird auch für dir MAC Register der normale >Lesebefehl wie für die anderen Register benutzt; auch praktisch >funktioniert bei mir nur dieser. Achtung, man muss bei allen Regs die mit MA oder MI anfangen ein dummy byte lesen. In der avrlib wird es dadurch realisiert dass die ganzen defines mit 0x80 (bit7) verodert werden. Bit7 wird sonst nicht genutzt -> es wird als Flag verwendet um zwischen normal und extra dummy umzuschalten (clevere idee btw). Die MAC regs werden auch alle mit extra dummy ausgelesen (siehe enc28j60.h ....|0x80 ) Hängt sonst noch was am SPI ? Wenn ich mein ISP Kabel nicht abziehe kommt auch nur murks an. Wie hoch ist deine SPI BAudrate / welche chiprev ? Laut errata soll man mit >8mhz lesen. Bei mir gehts aber auch mit den ersten Samples mit 7.32/2 mhz... Bye, Simon
Note that the code from AVR-Lib does not implement the erratas. You need to modify the code in a few places, to make workaraounds for Errata #2,6,12 and 13. Especially #13 is important. Without these modifications/workaraounds, the driver is unreliable. I have no problems with using lower speed than 8 MHz either. /Jesper
@jesper: how do you fix #6 ? if i try to use:
1 | if (enc28j60_read_address(ENC28J60_REG_EPKTCNT) == 0) |
2 | return; |
instead of
1 | if ((enc28j60_read_address(ENC28J60_REG_EIR) & |
2 | (1<<ENC28J60_BIT_PKTIF)) == 0) |
3 | return 0; |
it receives some packets ~10 times... the PKTIF flag works as expected. (rev2 of enc28j60) #13 never happened during my whole tests... Bye, Simon
@ssss also als Controller benutze ich einen Renesas M16C/62P. Wie hoch die SPI Frequenz bei mir jetzt genau ist, kann ich im Moment nicht sagen, da ich SPI zur Zeit nur softwaremässig implementiert hab (um die Probleme mit dem Hardware SPI in den Griff zu bekommen werd ich mir das mal mit einem Logic Analyzer genauer anschaun müssen). Die Taktfrequenz des Controllers beträgt 24Mhz. (d.h. schätzungsweise hab ich bei den getestesteten SPI-Clocks einen Bereich von irgendwas bis 10MHz abgedeckt) Habe aber auch schon ziemlich mit den diversen Delays herumprobiert, ohne merkbarer Veränderung des Verhaltens. Prinzipiell funktioniert ja das Auslesen der Register; Hierzu die Ausgabe der Register nach der Initialisierung des ENC: RevID: 0x2 EIE: 0x0 EIR: 0x0 ESTAT: 0x1 ECON2: 0x80 ECON1: 0x7 MAC MACON1: 0xD MACON2: 0x0 MACON3: 0x32 MACON4: 0x0 MACADDR 0x66 0x55 0x44 0x33 0x22 0x11 Rx ERXSTL: 0x0 ERXSTH: 0x6 ERXNDL: 0xFF ERXNDH: 0x1F ERXWRPTH: 0x0 ERXWRPTL: 0x0 ERXRDPTH: 0x6 ERXRDPTL: 0x0 ERXFCON: 0xA1 EPKTCNT: 0x0 MAMXFLH: 0x5 MAMXFLL: 0xEE Tx ETXSTH: 0x0 ETXSTL: 0x0 ETXNDH: 0x0 ETXNDL: 0x0 MACLCON1: 0xF MACLCON2: 0x37 MAPHSUP: 0x10 Teste ENC Speicher ... OK Initializing Network Stack Initializing Network Device Initializing ARP cache Initializing Addressing Eth Addr is: 102:85:68:51:34:17: IP Addr is: 192.168.0.20 Network Stack is up! MAC is not linked! MAC is TX ready Starting packet receive loop
In start of enc28j60PacketReceive, I have this :
// check if a packet has been received and buffered
if( !(enc28j60Read(EIR) & EIR_PKTIF) )
{
// Errata workaround #6, PKTIF is not reliable
// double check by looking at EPKTCNT
if (enc28j60Read(EPKTCNT) == 0)
return 0;
}
Errata #13 is fixed like this a little later in the same function :
/* old code
enc28j60Write(ERXRDPTL, (NextPacketPtr));
enc28j60Write(ERXRDPTH, (NextPacketPtr)>>8);
*/
// Errata workaround #13. Make sure ERXRDPT is odd
//
{
uint16_t rs,re;
rs = enc28j60Read(ERXSTH);
rs <<= 8;
rs |= enc28j60Read(ERXSTL);
re = enc28j60Read(ERXNDH);
re <<= 8;
re |= enc28j60Read(ERXNDL);
if (NextPacketPtr - 1 < rs || NextPacketPtr - 1 > re)
{
enc28j60Write(ERXRDPTL, (re));
enc28j60Write(ERXRDPTH, (re)>>8);
}
else
{
enc28j60Write(ERXRDPTL, (NextPacketPtr-1));
enc28j60Write(ERXRDPTH, (NextPacketPtr-1)>>8);
}
}
Sorry about the format, but I can find documentation of which tags to
use to make the code look nice and readable, like Simon did.
/Jesper
I just saw your comment about #13 never happening for you. That's interesting, because I got that very often. The stack would hang and when I looked at the registers, ERXRDPT was even. I added the fix, and it's been running for days now. The test server is at http://www.slugone.mine.nu /Jesper
I checked my code and i saw that i always use an even number for the rx pointer. My RX Region starts at 0x0602 and i have not recognized any problems yet. the counter goes up to 0x1FFF and then wraps around to 0x0602. the revision register says it is an 0x02 revision (DIP) you can format your code by using [ c ] code [ /c ] (without the extra spaces) it seems like i killed your server... i klicked multiple times reload to see how the counter works. Then after ~5 tries the server does no longer respond :-X sorry... Bye, Simon
Um diesem Thread hier ein positives Ende zu geben : Der ENC läuft jetzt; allerdings hab ich die ganzen Funktionen (bis auf das Software-SPI) neu geschrieben. Als Vorlage hab ich aber diesmal die Microchip Firmware selber gewählt (wo dann auch gleich die Erratas eingearbeitet sind). Bin jetzt grade dran den ganzen Stack selber neu zu schreiben (der Microchip Code ist mir zu aufgebläht). Was mir da aber aufgefallen ist: Es wird dort nirgends das MARST Bit zurückgesetzt; auch ein Register Dump nach der Initialisierung zeigt, daß das Bit noch gesetzt ist. Das Senden eines IP und ICMP Packets funktioniert aber einwandfrei (grad nochmal getestet weil ich mir nicht sicher war). Braucht dieses Bit entgegen dem Datenblatt doch nicht selber zurückgesetzt werden ? Oder geschieht das irgendwie anders ? Wie gesagt, bei mir funktionierts auch so; es würd mich jetzt nur interessieren wieso das nichts ausmacht, bzw was ich da übersehe ... Schöne Grüße, Thomas
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.