AnsweredAssumed Answered

LPC1778 MAC Address

Question asked by Alexander S on Feb 9, 2017
Latest reply on Mar 9, 2017 by Alexander S

Hello! I use LPC1778 Ethernet and noticed a bit strange behaviour.
Excuse me please for the long introduction.

 

During initialisation the ENET the Station Address registers SA0..SA2 must be loaded with the Ethernet MAC-address.
As User Manual UM10470 tells, the station address must be loaded into registers corresponding way, shown on the figure 22 in user manual. In particular, chapter 10, "10.10.1.15 Station Address 0 Register", references to figure 22: "For the ordering of the octets in the packet please refer to Figure 22." (C). Therefore, it is obviously from context that the numbers (octet1, octet2, etc.) of SA0..SA2 octets is the same as at Figure 22.

 

I have noticed that the order of bytes on Firgure 22 was changed since 2013 year (rev 2.1), and in current version (rev 4.0 from December 2016) it changed to reverse order. This fact is described on document revision history.

So, I load MAC address in accordance with the documentation (rev 4.0).

 

Besides the MAC-address, the Receive Filter register RXFILTERCTRL must be configured during the initialisation procedures. In accordance with the documentation, Bit 0 AUE, AcceptUnicastEn, is responsible for receiving all unicast frames, including the frames addressed to this local station. Bit 5 APE, AcceptPerfectEn, is responsible for receiving an unicast frames addressed to this local station only, by matching the hardware address (SA2..SA0) and destination address inside Ethernet-frame.

So, I do not set bit 0, but set bit 5, due to I need receive the unicast frames addressed to my device.

 

And... it does not work! I do not receive any frames.


I found out that setting the bit 0 (AUE) allows device to work, but the device have to process all unicast frames, that reduces the performance, so I'm not able to use such work-around method. Frankly saying, it is logically wrong way.

I had began to searching an answer and I found out that the changing the octets order during loading the registers SA2..SA0 to reverse order fixes my problem!


If I load the registers SA2..SA0 accordance with the documentation (rev 2.1) with reverse octet order, the device works without setting AUE bit, that indicates, in my opinion, the first variant of octet order was right.

In summary, I suspect that the current revision of User Manual (4.0) contatins an error, that was be made by changing the correct octets order in Figure 22 to the reverse wrong order. This fact is confirmed by my tests, represented below.
Or even if to leave the octets order on Figure 22 as is, it is required to not reference to Figure 22, because the octets order in Ethernet-frame (Figure 22) and octets order in SA2..SA0 does not match.

-------

Let's show more specifics: e.g. my MAC-address is 00-AA-BB-CC-DD-EE. So, octet 1 is 00, octet 2 is AA, and etc.
In Ethernet-frame the octets follows the same way, see ICMP packet as an example below.

Ethernet frame:
| 0000 | 00 AA BB CC DD EE 1c af f7 6b 97 6e 08 00 45 00
| 0010 | 00 3c 25 6c 00 00 80 01 94 01 c0 a8 00 01 c0 a8
| 0020 | 00 02 08 00 32 74 00 01 1a e7 61 62 63 64 65 66
| 0030 | 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76
| 0040 | 77 61 62 63 64 65 66 67 68 69

Ok, during tests I clear bits ABE (AcceptBroadcastEn) and AME (AcceptMulticastEn) in RXFILTERCTRL register to disable receiving any broadcast and multicast packets.
I tested the device by sending ICMP packets by PING and sending RAW Ethernet frames by special software (ethPack).

-------

Test 1:
1) SA2..SA0 is loaded in accordance with the documentation (rev 4.0);
SA0 = 0x000000AA
SA1 = 0x0000BBCC
SA2 = 0x0000DDEE
2) Bit AUE is set;
RXFILTERCTRL = 0x00000021 (AUE | APE)

Device works, it receives a unicast frames addressed to 00-AA-BB-CC-DD-EE.

-------

Test 2:
1) SA2..SA0 is loaded in accordance with the documentation (rev 4.0);
SA0 = 0x000000AA
SA1 = 0x0000BBCC
SA2 = 0x0000DDEE
2) Bit AUE is cleared;
RXFILTERCTRL = 0x00000020 (APE)

Device does not work. No packets received.
Using special software ethPack I generated user-defined frame with the destination MAC-address EE-DD-CC-BB-AA-00 and sent it.
And device received it!

-------

Test 3:
1) SA2..SA0 is loaded in accordance with the documentation (rev 2.1), reverse order;
SA0 = 0x0000EEDD
SA1 = 0x0000CCBB
SA2 = 0x0000AA00
2) Bit AUE is cleared;
RXFILTERCTRL = 0x00000020 (APE)

Device works, it receives a unicast frames addressed to 00-AA-BB-CC-DD-EE.

Test 4:
1) SA2..SA0 is loaded in accordance with the documentation (rev 2.1), reverse order;
SA0 = 0x0000EEDD
SA1 = 0x0000CCBB
SA2 = 0x0000AA00
2) Bit AUE is set;
RXFILTERCTRL = 0x00000020 (APE)

Device works, it receives a unicast frames addressed to 00-AA-BB-CC-DD-EE.

-------

So, As you can see, the order of octets shown in the actual user manual does not correspond to the real octets order in the hardware, or it is required to note the fact of the order reversing in description of SA2...SA0 registers.

Please, anyone, give me a piece of advice, whether I'm right or not.

Outcomes