Interfacing with the ENC28J60

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.

The code is now under version control using SVN. You can checkout a copy at svn+http://svn.mlalonde.net/Ethduino or browse the repository on the Trac site. Packets are still not getting received by applications, but they are getting sent (i can tcpdump them). As far as I can see, the checksum is definitely to blame. If anyone has an idea about this I'd really like to ear. As for running on the Mega168, so far so good... there's a good 6~8k free without all the debugging stuff which laves enough room for some business logic. (there's still definitely more things that could be done to reduce code size even further)

I sorry if this post is rather dry when it should be rather high, but I don't have anything to show (I don't have LCD at hand to do the ethernet LCD or something). But here it is...

I have the honour to present you the very first ping replies!

PING 192.168.0.126 (192.168.0.126) from 192.168.0.12: 56 data bytes
64 bytes from 192.168.0.126: icmp_seq=0 ttl=64 time=1.341 ms
[...]
64 bytes from 192.168.0.126: icmp_seq=4 ttl=64 time=1.245 ms

--- 192.168.0.126 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.235/1.283/1.341/0.039 ms

I've written functions to allow using the ENC's internal checksum functions. And it worked! This is an issue however because as noted in the errata #15, use of the DMA for checksuming can cause drop packets. I guess for some this would be fine; it has the added advantage of having a zero footprint in the stack! Either ways this is a huge step as it confirms that the hardware is up and running and that most of the software runs fine!

There are no words to explain my joy! ;D ;D ;D

now that's sounding nice.
this is the beginning of a new chapter in arduino's history :smiley:

congratulations, i hope it will not take too long for a little http functionality.

best, kuk_

Congratulations! I hope you plan to share your hard work and success with the rest of us by posting a schematic and some code. :slight_smile:

I don't recall what your final application is? You're probably quite close to a working serial proxy app right now; a TCP connection (to allow HTTP) may be a bit more work...

-j

Kuk: at this stage there is no plan for TCP support. The mega168 is small and TCP processing is heavy. I'm not saying it won't come but there are other priorities. Just like kg4wsv was saying were closer from an EthProxy than anything... I will post details (schematic, doc, etc) very soon. Meanwhile, the code is available above.

And finally, in pictures ^-^


(Click for full flickr experience)

There's a lot more info, access to code and bug listing on the trac site.
There's still a lot of documentation work to be done, but it'll come!