Interfacing with the ENC28J60

Hi there, so I've set up an ENC28J60 with a MagJack connector. Built my first PCB to breakout the MagJack :smiley: I used the code and circuit described here. As far as the ethernet link is concerned it seems to work (both leds on the switch and the device light up when I plugin the cable). Now I'm trying to get µIP working properly. Everything seems to compile just fine (adapting it slightly to work with the API). Sadly nor the UDP or ICMP program work. Everything times out (the µC never answers). The Arduino seems to behave very weirdly and seems to reset every so often which is weird. I have a Rev B NG, and the ENC28J60 communicates over SPI, I wonder if this could be the cause (pin 13's led is always faintly lighted up).

You can find the code here.

I really wished I knew what was going on :confused:

I don't remember which rev mine is, but it sounds like the same problem I had, described in this thread.

-j

I'll see, I'm now testing with another driver/ip stack. I finally got Procyon AVRLib to build along with the makefile for the arduino. I'll post an update when I advance a little more.

So I'm still having issues. I'm trying to use AVRLib's net stack libraries but I can't see to add them to my sketch (either in the IDE or the Makefile)... any help would be appreciated!

I am very interrested in this project. I just got 3 ENC28J60 sampled :stuck_out_tongue:

Ok so the code is up and running. At the moment I seem to have some problem interfacing with the ENC. At least it's some progress.

I seem to be having problems interfacing with the ENC. The reg dump doesn't seem to work properly. You don't really need the magjack for this, pm me if you would like a copy of the latest code.

So I tried the pin 13 option and changed the resistor. That's not it either :confused:

I had similar problems trying to get the (ever-in-progress) Arduino ethernet working. I could compile and upload code using the AVRlib enc28j60 library just fine, but it never seemed to respond to pings. Please post if you make any progress. :slight_smile:

Ok so I can confirm I can read the revision ID (register 0x312, that is register 12h of bank 3) albeit two things strick me. The first is that the register was previously defined as "(0x12|0x60)" which definitely does not make 0x312. The second is that all the bits were inverted. I had to ~ in order to read the proper revision id. Do you believe that's normal?

I was reading the datasheet and this came to my eyes. What do you think? Had you guys tried this, was the ethernet prototype running at 3.3v or is this just not an issue?

I'm pretty sure it's got something to do the 3.3V to 5V conversion. Not sure exactly what.

And I'm pretty sure it's not, although it might well be a side issue, the level shift is probably a good idea in prod cause 3.3v is really on the logical edge for an AVR running at 5v. I can confirm that I have received packets on the AVR! I wouldn't say it's up and running, but it seems to work. To be honest I'm not sure what I did. I cleaned up around the code. Part of the problem was me being an idiot and declaring the ports "absolute" binary values when the sbi/cbi method is used throughout.

I couldn't just leave it at that.... here is some debugging info from the Arduino to satisfy your geek desires!

Initializing Network Stack!
Initializing Network Device
Initializing ARP cache
Initializing Addressing
Net Stack is up!
cmd> Received packet len: 64Packet Contents
     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  0123456789ABCDEF
     -----------------------------------------------  ---- ASCII -----
0 [ch65533] [ch65533] [ch65533] [ch65533] [ch65533] [ch65533]   [ch65533] [ch65533]  [ch65533]     [ch65533][ch65533][ch65533][ch65533][ch65533][ch65533]..[ch715].[ch65533]....
16        [ch65533] [ch65533]  [ch65533] [ch65533] [ch65533]    ........[ch715].[ch65533][ch65533]..
32       [ch65533] [ch65533]  ~        ......[ch65533].~......
48             [ch65533] [ch65533] [ch65533] [ch65533]  ............[ch31341][ch65533]
NET Rx: ARP packet
Received ARP Request
ARP Packet:
Operation   : REQUEST
SrcHwAddr   : ::[ch65533]:[ch65533]::[ch65533]
SrcProtoAddr: [ch65533].[ch65533]..
DstHwAddr   : :::::
DstProtoAddr: [ch65533].[ch65533]..~
Sending ARP Reply
ARP Packet:
Operation   : REPLY
SrcHwAddr   : C:0:F:F:E:E
SrcProtoAddr: [ch65533].[ch65533]..~
DstHwAddr   : ::[ch65533]:[ch65533]::[ch65533]
DstProtoAddr: [ch65533].[ch65533]..

I just noticed that out of the 3 copies of the drivers, two are pretty much the same and implement the ENC28J60 Rev.B4 errata... Not Rev. B5, which is the same as my chip, if I read EREVID – and seems to be anything manufactured >= 2006. Had you guys worked these out or where you running on version 4? Because there are a few more erratas in rev 5 for Rx/Tx and mostly in Half Duplex sending!

EDIT: As far as I can see, errata #12 and #13, which both affect transmission have not been fixed yet.
EDIT++: Sorry I forgot the link http://ww1.microchip.com/downloads/en/DeviceDoc/80264d.pdf.

So after some more testing I was pretty sure the spi voltage had something to do with it. Even just dumping the registers (slower than I can click on a key) and the data would become inconsistent. And so the SPI input voltage problem has been solved. Using a SN74LS08 series AND gate running at 5v. two inputs are tied to the MISO of the ENC and tied to a pull down resistor. The output end up being ~4.5v, which is higher enough than the 2/3Vcc ratio the I/Os require (making 3.3v on the edge). Register readings now seem 100% consistant. I have also replace the 2.7k resistor on RBIAS by a 2.3k as noted in the Rev B5 errata. I definitely can read icmp, udp and tcp packets. More to come :smiley:

Time    Eth Address    IP Address
---------------------------------------
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
   0:0:0:0:0:0  0.0.0.0
Received ARP Request
ARP Packet:
Operation   : REQUEST
SrcHwAddr   : 0:16:CB:8B:1:EC
SrcProtoAddr: 192.168.0.12
DstHwAddr   : 0:0:0:0:0:0
DstProtoAddr: 192.168.0.126
Sending ARP Reply
ARP Packet:
Operation   : REPLY
SrcHwAddr   : CC:0:FF:FF:EE:EE
SrcProtoAddr: 192.168.0.126
DstHwAddr   : 0:16:CB:8B:1:EC
DstProtoAddr: 192.168.0.12

NET Rx: IP packet
Time    Eth Address    IP Address
---------------------------------------
d   ::[ch65533]:[ch65533]::[ch65533]  [ch65533].[ch65533]..
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
entering netstackIPProcess
NET Rx: UDP/IP packet
-1012UDP packet, len: 50
C1

  NET Rx: IP packet
Time    Eth Address    IP Address
---------------------------------------
d   ::[ch65533]:[ch65533]::[ch65533]  [ch65533].[ch65533]..
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
entering netstackIPProcess
NET Rx: TCP/IP packet
Rvd tcp Packet: len=68
NET Rx: IP packet
Time    Eth Address    IP Address
---------------------------------------
d   ::[ch65533]:[ch65533]::[ch65533]  [ch65533].[ch65533]..
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
   :::::  ...
entering netstackIPProcess
NET Rx: TCP/IP packet
Rvd tcp Packet: len=68

(the packets were sent using ping, nc and nc -u)

Awesome. Keep us posted.

More fooling around the registers (and I might have removed my way off specs ferrite bead meanwhile) and... this happened http://pastie.textmate.org/private/qrg8ojxbtjsjqyh1bmc8fa. And then it happened again! The transmitted packets, I never received anything though. Snooping with wireshark reveals that both packets failed CRC which might be why nc/ping didn't pick them up. But the Arduino did and it definitely sent!

The latest code can be obtained here. Have fun :slight_smile:

I'm in the process of seeing what I can do with µIP, it seems to have better checksum handling at least. And I wouldn't mind switching as µIP has a much better stack and properly support tcp.

EDIT: Doesn't seem like such a good idea. uIP is a little too feature complete for a mega168. And I won't even talk about OpenTCP. Looks like I'm going to stick with AVRLib.