Honored Contributor
Honored Contributor--- quote start ---
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.[/b]
--- quote end ---
in my case i have found that the 0x00 byte does get written, but because the packet length is reported incorrectly, not enough bytes are read to reach the 0x00 byte, instead we end up half-way through the packet! (this is what i was trying to show with my previous post)
<!--quotebegin-chmike@Nov 8 2006, 06:25 PM 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. --- Quote End --- Yes, bit 6 does indeed signify multicast --- according to a line in the "Application Notes" datasheet, this status byte is the same as the RSR register (RX status), which is described on page 16 of the other datasheet. --- Quote Start --- originally posted by chmike@Nov 8 2006, 06:25 PM 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. --- Quote End --- I can't find any information about these bits in the datasheets... although one line does imply that they should all be 0 except the 1st bit: "The first byte is used to check whether a packet is received and filtered in the RX SRAM. If this byte is "01", it means there is a packet received. If this byte is "00", it means there is no packet received in the RX SRAM." However, everywhere else (including the example code), it just checks the first 2 bits. In my testing, I have found that (before the incorrectly received length causes it to break), this byte is always "01" or "00". You have different results? --- Quote Start --- originally posted by chmike@Nov 8 2006, 06:25 PM 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.
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=19304)
--- quote end ---
--- Quote End ---
