Re: [uip-users] uIP 0.9 on ATMega128 webserver problem

[Jack Peacock]

Rui Carvalho wrote:

With I access the server through any browser, I can get one or two
pages with gifs, but then the webserver stops working.
Then it doesn't respond to ping, but the code is still running, since
I can get answers from the serial port (pressing any key in a terminal
I get the "unknown message").

I saw the same kind of problem using uIP 0.9 on an MSP430 and ENC28J60 
(B1 silicon rev).  I traced it down to a problem reading the packet 
count register on the ENC28J60.  Typically the poll routine will check 
the packet count to see if the ENC's buffer contains completed read 
packets waiting to be processed.  I noticed that on some occasions when 
the packet count got to 2 or more waiting it would lose one packet, so 
the register would be one message behind the actual packet count.  The 
net effect would be to stall uIP, especially on TCP connections.  Ping 
stopped working too.

Here is a code segment showing how I check for waiting packets.  It has 
been working reliably.

int enc28j60_poll(void)
{
 static unsigned int len, rxptr, i, j;
 static unsigned char rsv[6];
 static RXSTATUS *rsvptr;

 i = enc28j60_read(EPKTCNT);                    // any waiting packets?
 if (i == 0)
 {
     do
     {
       i = enc28j60_read(EPKTCNT);
       len = enc28j60_read(ERXWRPTL);           // ERXWRPT, always read 
lo byte first
     len |= (enc28j60_read(ERXWRPTH) << 8);    // get next packet ptr
     j = enc28j60_read(EPKTCNT);
     } while(i != j);                                        // stable 
read of ERXWRPT if pkt cnt same
     if(j == 0)
     {
       if(len == rxptr) return 0;                // buffers in sync, 
then no data
     if(enc28j60_read(ESTAT) & 0x04) return 0;    // incoming buffer, 
try later
       if(enc28j60_read(EIR) & 0x40) return 0;    // incoming busy, try 
later
     }                                            // no pkts, not busy, 
bufs out of sync, recover
 }
// gets to here, packet receive status ready to read in at ERXRDPT 
pointer in the buffer

The trick is to make sure the packet count (EPKTCNT register) is 
consistent with the packet write pointer register not being busy.  The 
packet count seems to only be reliable if no packet is being received 
(i.e. the ERXWRPT registers do not change between reads of EPKTCNT).

This may be related to an errata sheet problem with the ENC28J60, which 
says the minimum SPI clock speed has to be 8Mhz.  The MSP430 has a 
maximum SPI clock of 4Mhz. if using an 8Mhz crystal.
 Jack Peacock