LPC1778 MAC Address

alexanders · ‎02-09-2017

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.

jeremyzhou · ‎02-14-2017

Hi Alexander,

Thank you for your interest in NXP Semiconductor products to serve you.

After have a look through the description above, I really appreciate your reporting very much.

Next, I was wondering if you can share the testing demo and introduce the testing steps to replicate the issue in details.

And I'll contact with the AE team for checking if I confirm the issue.

I'm looking forward to your reply.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

alexanders · ‎02-16-2017

Hi, jeremyzhou ,

sorry for the long answer, I had problems with loging in my account.

So, I use TNKernel RTOS in my project.

I do not think that the sharing the whole project is a good idea, but I guess that the sharing of the ENET-driver part is quite enough.

It is quite complicated to check the problem on real device, because it is needed to have PCB with specified hardware, e.g. LAN8720 PHY level.

You can download the TNNet sources here: TNKernel real-time system

This is a part of the my project responsible for processing and functionality of ENET (Ethernet).

Please, follow 'tn_net\cpu_lpc23xx' directory inside the ZIP-archive (tn-net-0-9-src.zip, accessible by the link above).

And open 'lpc23xx_mac.c' source file.

The ENET of lpc23xx and lpc17xx works similary, there for this sources works fine.

Please, refer to 'int init_mac(TN_NETINFO * tneti)' function.

Also, you can refer to 'lpc23xx_net.c' to find out how the MAC-address is loaded to ni->hw_addr

In example, MAC-address is 10:0C:CC:22:33:44.

So, Ethernet frame addressed to the device begins with the following bytes:

0000: [10 0C CC 22 33 44 ] [ Source MAC address ] [ Ethernet frame type ]

Octet 1 - 0x10, octet 2 - 0x0C, and so on.

Following code is responsible for loading the Station Addres into hardware:

rMAC_SA0 = (ni->hw_addr[0] << 8) | ni->hw_addr[1];
rMAC_SA1 = (ni->hw_addr[2] << 8) | ni->hw_addr[3];
rMAC_SA2 = (ni->hw_addr[4] << 8) | ni->hw_addr[5];

The code is corresponds to the current actual User Manual.

My testing steps was:

Step 1.

1) SA2..SA0 is loaded in accordance with the documentation (rev 4.0);

rMAC_SA0 = (ni->hw_addr[0] << 8) | ni->hw_addr[1];
rMAC_SA1 = (ni->hw_addr[2] << 8) | ni->hw_addr[3];
rMAC_SA2 = (ni->hw_addr[4] << 8) | ni->hw_addr[5];
2) Bit AUE is set;
rMAC_RXFILTERCTRL = 1 | //-- Bit 0 AcceptUnicastEn
(1<<1)| //-- Bit 1 AcceptBroadcastEn
(1<<2)| //-- Bit 2 AcceptMulticastEn dif
(1<<5); //-- Bit 5 AcceptPerfectEn

Device works, it receives a unicast frames addressed to my MAC-address.

Step 2.
1) SA2..SA0 is loaded in accordance with the documentation (rev 4.0);

rMAC_SA0 = (ni->hw_addr[0] << 8) | ni->hw_addr[1];
rMAC_SA1 = (ni->hw_addr[2] << 8) | ni->hw_addr[3];
rMAC_SA2 = (ni->hw_addr[4] << 8) | ni->hw_addr[5];
2) Bit AUE is cleared;
rMAC_RXFILTERCTRL = 0 | //-- Bit 0 AcceptUnicastEn
(1<<1)| //-- Bit 1 AcceptBroadcastEn
(1<<2)| //-- Bit 2 AcceptMulticastEn dif
(1<<5); //-- Bit 5 AcceptPerfectEn

Device does not work. No packets received.

Step 3.

1) SA2..SA0 is loaded in accordance with the documentation (rev 2.1), reverse order;
rMAC_SA0 = (ni->hw_addr[5] << 8) | ni->hw_addr[4];
rMAC_SA1 = (ni->hw_addr[3] << 8) | ni->hw_addr[2];
rMAC_SA2 = (ni->hw_addr[1] << 8) | ni->hw_addr[0];
2) Bit AUE is cleared;
rMAC_RXFILTERCTRL = 0 | //-- Bit 0 AcceptUnicastEn
(1<<1)| //-- Bit 1 AcceptBroadcastEn
(1<<2)| //-- Bit 2 AcceptMulticastEn dif
(1<<5); //-- Bit 5 AcceptPerfectEn

Device works, it receives a unicast frames addressed to my MAC-address.

Step 4.
1) SA2..SA0 is loaded in accordance with the documentation (rev 2.1), reverse order;
rMAC_SA0 = (ni->hw_addr[5] << 8) | ni->hw_addr[4];
rMAC_SA1 = (ni->hw_addr[3] << 8) | ni->hw_addr[2];
rMAC_SA2 = (ni->hw_addr[1] << 8) | ni->hw_addr[0];
2) Bit AUE is set;
rMAC_RXFILTERCTRL = 1 | //-- Bit 0 AcceptUnicastEn
(1<<1)| //-- Bit 1 AcceptBroadcastEn
(1<<2)| //-- Bit 2 AcceptMulticastEn dif
(1<<5); //-- Bit 5 AcceptPerfectEn

Device works, it receives a unicast frames addressed to my MAC-address.

If you need the other proofs, I will try to create testing project and upload it, but I think the provided data is enough.

In general, the device does not receive Unicast frames address to it's MAC-address if the AUE bit is cleared.

But if the order of octet is reversed, the device works properly.

jeremyzhou · ‎02-17-2017

Hi Alexander,

Thanks for your reply.

Yes, you are right, and I've also found that the Chip_ENET_SetADD function load the SA0~SA2 in the reverse order.

/**
 * @brief     Sets the address of the interface
 * @param     pENET     : The base of ENET peripheral on the chip
 * @param     macAddr     : Pointer to the 6 bytes used for the MAC address
 * @return     Nothing
 */
STATIC INLINE void Chip_ENET_SetADDR(LPC_ENET_T *pENET, const uint8_t *macAddr)
{
     /* Save MAC address */
     pENET->MAC.SA[0] = ((uint32_t) macAddr[5] << 8) | ((uint32_t) macAddr[4]);
     pENET->MAC.SA[1] = ((uint32_t) macAddr[3] << 8) | ((uint32_t) macAddr[2]);
     pENET->MAC.SA[2] = ((uint32_t) macAddr[1] << 8) | ((uint32_t) macAddr[0]);
}
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

And I was wondering if you can share the Rev 2.1 document, and I think I need to contact with the AE team for checking.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

alexanders · ‎02-19-2017

Hi jeremyzhou !

yes, LPCOpen loads the registers this way, that actually confirms that the order should be reversed.

Of course, I shared the User Manual rev 2.1

This link refers to dropmefiles service and is available for 14 days since today.

Please, if you can't download it, try another browser, because my Google Chrome does not downloads this file, but Firefox does. Please, notify, if you will have problems with downloading.

Thank you very much.

Have a nice day,

Alexander.

jeremyzhou · ‎02-20-2017

Hi Alexander,

Thanks for sharing, I've already downloaded the file now.\(^o^)/
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

alexanders · ‎03-09-2017

Hi, jeremyzhou !
Is there any news about my issue?

When I can download new revision of UserManual?

alexanders · ‎02-20-2017

Okay, If you find out anything new, please, notify me.

Thank you very much,

Have a nice day,

Alexander.

LPC1778 MAC Address

LPC1778 MAC Address

LPC17xx