W5200 - Erratum 3 - MACRAW mode


#1

Hello,

Our company uses w5200 in our products. I need to receive RAW Ethernet frames. No IP layer. Just to capture RAW frames.

While testing I ran into the issue with Erratum 3. I test sending 60 bytes ARP frame to w5200. While receiving it I read the packet info as 62 or 63 instead of 60. I don’t see any dummy bytes appended until the next packet info. After 60 bytes, the next packet info is available.

Below is the quote from erratum 3 for w5200

  • When the received packet size is larger than the actual received packet size.
    The received MACRAW data format is shown in the figure below. The PACKET-INFO (the
    byte size of data packet) can also be larger than the actual packet size in this
    phenomenon. Therefore, the Dummy data is inserted from the actual packet size to the
    PACKET-INFO size.

The problem with the provided solution is I don’t use any ip layer, I just want to capture the raw frames which includes ARP packets. Since no dummy bytes are getting appended and the packet info is incorrect, I don’t know how much bytes to read.

My question is, why am I not seeing dummy byte getting appended? This behavior is not as expected in the errata! What is the solution to receive ARP frame/ any other frame without using IP information? Is it possible?


#2

Hi, lr15.

Appended dummy data means broken data.

| data length , broken data | real data |
|--------- 2 byte --------------|
So, it seemed larger than real data length.

And W5200 has auto-reply about ARP request. So you don’t need to take care about it.

If you tell me more why you want to read ARP packet, I guide you in more detail.

And valid ARP data is 42bytes and others is padding data so, you can parse to read data as Sn_RX_RD for length and write data length to Sn_RX_WR as same as Sn_RX_RD.

Best regards.


#3

Hi hjjeon0608, Thanks for the response.

As for the work I’m doing I need to capture and store all the Ethernet frames to analysed later. So all the Ethernet frames irrespective of their Ethernet type has to be captured. This is only a Layer 2 operation. This is not about ARP, I just gave an example. It could be any ether type. en.wikipedia.org/wiki/Ethernet_frame

"And W5200 has auto-reply about ARP request. So you don’t need to take care about it."
Incorrect. w5200 will not reply for ARP in MACRAW mode. How can it reply, I don’t have an IP! I’m just handling RAW Ethernet frames with MAC address, a Layer 2 operation.

So all it means is, the reported packet info will be wrong - it contains actual length + dummy length and NO DUMMY data is actually inserted. Is this correct? If this is correct, how can I find the actual received length so that I can read the Ethernet frames? Is it possible to receive just Ethernet frames - only Layer 2 operation. No IP layer?


#4

Hi, lr15.

I understand your questions.
If you don’t set source IP address, W5200 doesn’t send ARP reply, and you are right.
So ignore my statement about this.

Dummy data is broken data inserted in packet-info as I said, so it is always in PACKET-INFO 2 bytes.
And real data has no dummy data.

| real data length + dummy data | real data |
|---------- 2 bytes ---------------|
| packet-info |

So, you can read real data after ignoring packet info(2 bytes).
And you can know data length as reading Sn_RD_RSR register and this contain packet info so (Sn_RD_RSR value - 2) is real data length.

Best regards.


#5

Glad to see you in sync with my question :slight_smile:

“So, you can read real data after ignoring packet info(2 bytes). And you can know data length as reading Sn_RD_RSR register and this contain packet info so (Sn_RD_RSR value - 2) is real data length.”

Problem with your solution is the RX FIFO can accumulate packets i.e it could contain more than one packet.

ex:) two packets; 60 bytes and 70 bytes. But packet info says 62 and 73. Sn_RD_RSR says 134.

|------2 bytes -----|------60 bytes data-------|-----2 bytes----|-------70 bytes-------|
| packet-info - 62 | Ethernet frame | packet-info - 73 | Ethernet frame |

It is not possible to extract since Sn_RD_RSR now doesn’t denote the packet length since there are many packets. This will not work. Am I missing something?


#6

Hi, lr15.

I think it is impossible to parse not IP packet because of the problem as you said.

I’m sorry for that. And I suggest to change chip to you.
5100, 5300, 5500 has no bug about this. So, you can handle it.

I apology again.

Best regards.


#7

w5300 is used in one of our products. It works without this issue in MACRAW mode. Replacing with w5300 is not an option, it has much more pins and it will be hard to fit in.

w5100 doesn’t meet the criteria as 8 sockets are required.

w5500 looks to have similar pin out, register settings and functionality as w5200. I’m not able to locate the Errata sheet for w5500 in your website? Can you provide it?

Thanks


#8

Hi, lr15.

We fixed that bug and we tested aging. The result has no problem until now.

In other words, we don’t have errata sheet about W5500.

Best regards.


#9

Can W5200 be purchased that does not have this bug? We would like the flexibility to use IND or SPI with the w5200 without bug.