uCos with a DM9000A

Hi

sorry, didn't saw you posted an answer.

I also did many tests and found out the same result. Looking at the driver's design, it looks as if the controler appends a 0x00 after each valid packet. The driver use this to detect that there are no more packets to read. This byte gets superseeded with 01 when a valid packet is received.

The bogus situation is when the 0x00 byte is apparently not written. This is clear with your dump because the value found there is the payload of previous pings filled with increasing byte value. When the byte has the bit1 set, this triggers a reset of the controller, but when by accident bit0 and bit1 are both 0, then the driver enters an endless loop because it thinks this is value 0.

The question is thus, why this 0x00 byte is not written and in your case why it gets a packet with invalid length. Which is worse.

Here is more info on the two first status bytes of pakets I found out. Unfortunately they are not documented in the data sheat I have. Lets call the two first bytes of the packet header S1 and S2.

niosIIuser apparently had knowledge on some of the S2 bits that he tests in his driver. bit 7 = length err , bit 5 = crc error, bit 4 = Fifo overflow. I noticed that bit 6 is on when the packet is an ARP multicast packet. It could signal Ethernet multicast packets. No info on other bits.

I beleive the S1 bits have the following meaning: bit0 = valid packet avail, bit 1 = 0, bit2 = ip packet, bit3 = TCP packet?, bit4=UDP packet.

I have three drivers and all drivers are quite different in the way to handle packets. Only the web server driver rely on the 0x00 byte value after a packet.