uEthernet - Debuging the Driver
I tend to debug my code from the bottom up. So in the case of the ENC28J60 driver
the lowest level code is the SPI driver. To test SPIWrite, I wrote a small function
in main to write a number of bytes (normally and array filled with 0xaa or 0x55)
from the SPI port. Then using a cheap PC based logic analyser I monitored all 4
pins. The image below is screenshot from LPC2106 SPI port capturing a write sequence.
Further testing with larger packets and different clockrates was done I just dont
deem it necessary to bore you with the details. One funny I did notice whilst debugging
the SPI was the speed (or lack of) of the GPIO pin used for CS. I had to write a
small macro that checked the CS went high before moving on, without the check the
next command had started executing before CS was released.
The ENC28J60 driver has 3 main public functions that the calling code uses. However,
as you may have seen whilst browsing the code documentation there a number of private
functions also.
The private functions are all used to read and write to the various registers within
the ENC28J60. All the private functions were debugged by using the pc analyser.
Once all the low level read and writes were checked I could now attempt to configure
the MAC and start transmitting and receiving packets.
I figured a good test would be to broadcast an ARP request to a known IP address. The target for my ARP request is my home PC. If I successfully transmit an ARP packet
from my uCEthernet boad with my PC's IP address, my PC will send a reply ARP packet.
To make life a little easier I used Ethereal to monitor the transactions, this would
highlight any problems fairly quickly.
A demonstration of the code sending and receiver the ARP packet can be seen here.
Ok so the driver is working, of sorts, we know that we can transmit and receive
packets successfully, however, on its own its not that great or particulary useful.
On the next page we will begin looking at integrating the driver with a TCP/IP
stack.
Page 6