Ethernet LPC1769 CRC

[lpcware]

Content originally posted in LPCWare by DMH on Sat May 30 17:58:20 MST 2015
Hi.

I have a LPC1769 board and i'm trying to use the uIP stack to achieve ethernet connectivity so that I can access the board through ethernet connection.

Everything seems to be working perfectly except the CRC part.

I've configured the MAC2 to pad to 64bytes and append the CRC. Wireshark indicates the packet has been received but the CRC is invalid (the value reported by Wireshark is of 0 when it should be a certain value).

So I noticed that the descriptors also have a padding and appending CRC flags so enabled those as well and the problem remains.

The entire packet is exactly as expected except for the frame check sequence.

I've enabled (and disabled) pretty much any option regarding the padding and CRC parts of the Ethernet block and it won't work. If only the padding and appending CRC flags are enabled (MAC2 flags off) the packet will be sent but discarded by Wireshark as its size is inferior to the required minimum (42 bytes vs 64 bytes).

In my attachment is the Ethernet device driver. (Please take into consideration that I'm still in college so my code isn't up to professional standards).

Thank you.

Original Attachment has been moved to: EMAC.zip

[lpcware]

Content originally posted in LPCWare by capiman on Mon Jun 01 22:43:09 MST 2015
Hi DMH,

which Ethernet PHY (Ethernet chip) are you using? The 8720?
Have you checked if the Ethernet init is successful?
Can you send Ethernet packets via your attached code?
Have you checked, if you can receive data via your attached code (before they are sent to uIP)? So you can say error is in EMAC code or in uIP code...
I think to remember that Ethernet buffers must be in certain memory area. Have you checked?

Is the board something readily available (which one? Keil board?) or have you created your own board?

Could it be something like Ethernet speed 10/100/1000 MBit/s?

Best regards,

Martin

[lpcware]

Content originally posted in LPCWare by DMH on Mon Jun 01 19:57:25 MST 2015

---

Quote: MikeSimmonds
The next issue(s) then are (in 1769 user manual terminology) Station Address [MAC ADDRESS]
and RXFILTERCTRL.

I set my RXFILTERCTRL to 0x26 [MAC ADDR Match + Broadcast + Multicast] You need broadcast for ARP

Depending on the revision of your user manual, there may be a bug in the description of the Station Address (MAC ADDRRESS)
registers.

Regardless, if your MAC ADDR is 01-23-45-67-89-AB,

SA0 = 89-AB [0x89AB]
SA1 = 45-67  [0x4567]
SA2 = 01-23  [0x0123]

EDIT: I had another look at you posted code; the filtering is OK, the MAC address is backwards, due to some idiot in the
documation department, I think if you download that latest manual, they fixed it. Anyway, swap SA0 and SA2.

Mike

---

My manual is the latest on available on their website, I'll try your solution.


Edit: I've tried swapping, still the same result. Do I have to do anything to the used descriptor? Like set it to some initial value or something after reception?

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Jun 01 17:42:07 MST 2015
The next issue(s) then are (in 1769 user manual terminology) Station Address [MAC ADDRESS]
and RXFILTERCTRL.

I set my RXFILTERCTRL to 0x26 [MAC ADDR Match + Broadcast + Multicast] You need broadcast for ARP

Depending on the revision of your user manual, there may be a bug in the description of the Station Address (MAC ADDRRESS)
registers.

Regardless, if your MAC ADDR is 01-23-45-67-89-AB,

SA0 = 89-AB [0x89AB]
SA1 = 45-67  [0x4567]
SA2 = 01-23  [0x0123]

EDIT: I had another look at you posted code; the filtering is OK, the MAC address is backwards, due to some idiot in the
documation department, I think if you download that latest manual, they fixed it. Anyway, swap SA0 and SA2.

Mike

[lpcware]

Content originally posted in LPCWare by DMH on Mon Jun 01 15:12:21 MST 2015

---

Quote: MikeSimmonds
Have you implemented ARP protocol.
And ICMP for pinging.

---

The ARP protocol is implemented, I'm using the uIP TCP/IP stack so only ARP protocol and TCP is implemented on this example of theirs.

The issue is I see Wireshark capture a TCP frame but it never reaches the board or at least the board never recognizes it.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Jun 01 12:43:48 MST 2015
Have you implemented ARP protocol.
And ICMP for pinging.

[lpcware]

Content originally posted in LPCWare by DMH on Mon Jun 01 07:12:06 MST 2015

---

Quote: MikeSimmonds
The code in your zip does not seem to set MAC2 at all! (Commented out.)

On the 1778 (same EMAC module), I set MAC2 to

  MAC2_FULL_DUPLEX
  MAC2_CRC_EN
  MAC2_PAD_CRC_EN

I.e 0x31

And I don't have issues.

As mentioned, I had to set options on Wireshark and/or the Network adapter.
At this length of time, I can't really remember the full details.

Doesn't the MAC have any control over the network adapter?

Mike

---

I'm aware of the commented part, in the application it isn't commented, bad zipping on my part.

The MAC doesn't give you much control over this kind of things, nonetheless another thing that is weird is that although the MAC address of the board and its IP gets registered I can't access it through its IP address. The TCP packets never arrive at the board.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sun May 31 12:41:12 MST 2015
The code in your zip does not seem to set MAC2 at all! (Commented out.)

On the 1778 (same EMAC module), I set MAC2 to

  MAC2_FULL_DUPLEX
  MAC2_CRC_EN
  MAC2_PAD_CRC_EN

I.e 0x31

And I don't have issues.

As mentioned, I had to set options on Wireshark and/or the Network adapter.
At this length of time, I can't really remember the full details.

Doesn't the MAC have any control over the network adapter?

Mike

[lpcware]

Content originally posted in LPCWare by R2D2 on Sun May 31 12:32:16 MST 2015

---

Quote: MikeSimmonds
What is "an MBP"?

---

:D

Google:

Mac Book Pro

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sun May 31 12:27:25 MST 2015
What is "an MBP"?

See this for a fuller explanation.

You could have Googled this for yourself.

Mike

[lpcware]

Content originally posted in LPCWare by DMH on Sun May 31 06:35:07 MST 2015

---

Quote: MikeSimmonds
This is an 'issue' with your PC's network driver.

'Checksum offload' is enabled, so Wireshark never sees the CRC.
There is a Wireshark help or faq or wiki about this.

Got to the network options (can't remember where they are this week), but probably
somewhere in Device Mangler Network Adapters <device name> Properties Advanced
On mine there is "IPv4 Checksum Offload" which needs to be disabled for Wireshark
to see the packet CRCs.

Cheers, Mike

---

Ah since I'm using a MBP that option doesn't really show up. Or is the option on Wireshark?

Could that be the reason the browser can't access the web server on the LPC1769 board?

Everytime I try to go to the boards IP on the browser (192.168.0.2) it never seems to be able to connect.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sun May 31 06:22:04 MST 2015
This is an 'issue' with your PC's network driver.

'Checksum offload' is enabled, so Wireshark never sees the CRC.
There is a Wireshark help or faq or wiki about this.

Got to the network options (can't remember where they are this week), but probably
somewhere in Device Mangler Network Adapters <device name> Properties Advanced
On mine there is "IPv4 Checksum Offload" which needs to be disabled for Wireshark
to see the packet CRCs.

Cheers, Mike