This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP432E401Y: Source MAC filtering does not act

Part Number: MSP432E401Y

Hello support team!

I use MSP432E401Y. I write an assembly code in the Code Composer Studio.

I want to use standard MSP432E401Y abilities for MAC filtering. First of all I have tried to enable Destination MAC filtering. I write the MAC into EMACADDR0L and EMACADDR0H. Destination MAC filtering acts perfectly.

For Source MAC filtering I take next steps:

- I write the MAC address into EMACADDR1L and EMACADDR1H;

- I set bit 31 (AE) (The address filter module uses the second address for perfect filtering) and bit 30 (SA) (MAC Address1[47:0] is used to compare with the SA fields of the received frame) in the register EMACADDR1H;

- I set bit 9 (SAF) in the register EMACFRAMEFLTR (Source address filter enabled). All other bits of the EMACFRAMEFLTR are zeros.

You will ask how I check the filtering. I send to the MCU an Ethernet frames with following parameters:

- Destination MAC address of the frame does not match the address in EMACADDR0x

- Source MAC address of the frame matches the address in EMACADDR1x.

But DMA drops the frames. I think the frames shall be received, because bit 31 of EMACFRAMEFLTR is cleared (MAC RX module only passes frames that pass the SA or DA address filter).

 

Moreover I clear and bit 30 (SA) in EMACADDR1H (MAC Address1[47:0] is used to compare with the DA fields of the received frame) and send frames with Destination MAC address, that matches the address in EMACADDR1x. But DMA drops the packets again. The EMAC receives a frame, only if the Destination MAC field of the frame matches EMACADDR0x.

 

I do not find my mistake. It seems like EMACADDR1x is always disabled. The EMAC “does not see” the address placed in EMACADDR1x. But bit 31 (AE) = 1. I checked it in Registers window during debug session.

 Please, help me. I feel the mistake is small.

 

Best regards.

  • Hi Eugen,

    I don't see anything obvious you are doing wrong here based on your explanation. 

    Moreover I clear and bit 30 (SA) in EMACADDR1H (MAC Address1[47:0] is used to compare with the DA fields of the received frame) and send frames with Destination MAC address, that matches the address in EMACADDR1x. But DMA drops the packets again. The EMAC receives a frame, only if the Destination MAC field of the frame matches EMACADDR0x.

    Very interesting. Does the same failure occur when using EMACADDR2x? 

    I do not find my mistake. It seems like EMACADDR1x is always disabled. The EMAC “does not see” the address placed in EMACADDR1x. But bit 31 (AE) = 1. I checked it in Registers window during debug session.

    Just to be clear you are seeing the expected MAC Address is properly loaded during your debug session as well?

    What MAC Address are you setting bits [47:0] to in the EMACADDR1H register, and what address are you sending? 

    Best Regards,
    Brandon Fisher

  • Hello dear Brandon!

    Thank You very much for the reply. I answer Your questions.

    I did not try to use EMACADDR2x and EMACADDR3x for this task. I will do it (on Monday, not earlier).

    About EMACADDR1x and debug session. I have the MAC 00:39:11:2E:EE:22, therefore I write:

    EMACADDR1L := 0x2E113900

    EMACADDR1H := 0x000022EE

    Then I modify bits 31 and 30:

    EMACADDR1H := 0xC00022EE

    During debug session I see “0xC00022EE” in EMACADDR1H after all actions. Thus I write EMACADDR1H  rightly.

     

    Sending UDP frame has SA field = 00:39:11:2E:EE:22 and DA field = 00:39:11:2E:EE:21. From my point of view the EMAC must receive the frame, as its SA field matches EMACADDR1x. I add, that I write 00:39:11:2E:EE:90 into EMACADDR0x in order to avoid DA matching.

    Best regards.

  • Hi Eugen,

    My experience with MAC filtering on these devices is limited, but your settings for the register values based on your source and destination Addresses do look correct based on the TRM. You could try running a sniffer to capture the actual Ethernet traffic. 

    Best Regards,
    Brandon Fisher

  • Hello again, Brandon.

    I have tried to apply EMACADDR2x and EMACADDR3x too. The result is the same.

    I tried to check the filtering function from another side. I set bit 31 of EMACFRAMEFLTR, all other bits are zeros. In this mode “the MAC Receiver module passes all received frames, irrespective of whether they pass the address filter or not, to the application. The result of the SA or DA filtering is updated (pass or fail) in the corresponding bits in the Receive Status Word” (SLAU723A, pg.946). I check bit 30 (AFM) and bit 13 (SAF) of RDES0 during debug session (with a breakpoint). And I see, that bit 30 becomes “1”, but bit 13 is always “0”.

    Yes, I always check Ethernet traffic with WireShark. This application is very useful for programmer, as oscilloscope for an electronician.

    Please, dear Brandon, let me know, if You find useful peculiarities regarding MAC filtration.

    Best regards.

  • Hi Eugen,

    I am looking into this more to see if we have a similar example you can compare against. I will give you an update by tomorrow.

    It does seem to me that your register settings as you describe them should be correct for perfect filtering though. 

    Best Regards,
    Brandon Fisher

  • Hello Brandon.

    Thank You for the searching. I hope You will find the example.

    I have found a solution, but it is a bad solution. I filter the frames in software way, but not in hardware one. I know, it is abnormal solution, but it partly resolves my issue. On other hand, in this way I can create more sophisticated filter, which includes priority and various conditions.

    The true solution is yet interesting for me, so I shall wait for Your reply.

    Best regards.

  • Hi Eugen,

    Sorry for the delay here. I'm glad you at least have some kind of workaround in place currently. 

    Looking through our code base and checking with some of my colleagues its doesn't appear we have example code showing the perfect filter setup. that is true for both MSP432E401Y and TMP4C129 which has a similar ethernet peripheral with similar configuration requirements.

    I would ask to check your source code, but writing this in Assembly is probably beyond the scope of our ability to support.

    Best Regards,
    Brandon Fisher

  • Hello Brandon.

    Thank You very much in any case.

    Yes, I can give You a part of my code. The whole code is too large. But there are a lot of things, which are not understandable without whole code and commentaries… I can take a part of the code and remove then all the secondary details, translate commentaries into English. I need time to do it.

    Many people are surprised, when they hear, that I write in assembly code. It is so archaic. But I find an assembly code simpler and more understandable.

    Best regards.