• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 2039 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PRU-ICSS Ethernet

Laurent Joye
Prodigy 170 points
Other Parts Discussed in Thread: AM3359

Hi,

I'm using the AM3359 processor and the patched Linux kernel from TI so that the PRU is programmed with the PRU-ICSS Ethernet firmware.

It works very well if I start a dhcp client on the interface managed by the PRU. I can play with some IP protocols without any error.

But I'd like to use this ethernet interface to send and receive some frames related to the EtherCAT protocol. If I send a EtherCAT frame (considering I'm the master), the response is the mirror of the sent frame plus-minus the adaptations made by the EtherCAT slaves. The wireshark traces confirm that the request and its simultaneous response (EtherCAT principle) are correct. But the PRU doesn't inform the prueth Linux kernel driver of the response. There isn't any interrupt generated in such a case.

Any idea, any solutions?

Thanks for your help

  • 0
    TI__Guru**** 393215 points
    Hi,

    The PRU Ethernet experts have been notified. They will respond here.
  • 0
    TI__Mastermind 44306 points

    Laurent,

    I assume in this case you are using PRU-ICSS interface eth2 or eth3. I recently ran into the same issue as the MAC addresses for this interfaces seem to be randomly generated. In my case the address had the bit 1 of highest MAC byte (locally administered bit) set to 1. However EtherCAT assumes that this bit is not set on packets send by master. The slave will then set it and return the packet.

    Actually with this the send and receive packet have the same DST MAC and it equals the Ethernet interface MAC. So it will be filtered by the PRU EMAC as a looped packet. I could fix the issue by assigning a different MAC to eth2 which did not have this bit set (e.g. 00:55:44:33:22:11).

    I already filed this as an issue in PDK.

    Regards,

  • 0 in reply to Frank Walzer
    Prodigy 170 points

    I didn't knew the meaning of the 2 lowest bits of the first byte of a mac address

    Many ethernet controller could drop (to reduce CPU load) the frames in these cases:

    • the destination address is a multicast address and the host mac address doesn't match this address group
    • the source address matches the host address (loop packet filter)

    In case of EtherCAT frames, the master sends a frame and receives it back automatically. An EtherCAT slave will then set the second bit of the first byte of the source mac address to prevent the master ethernet controller to filter this packet. This can only work in the case the master mac address is not a locally administered address.

    In my case the mac address is randomly generated by the Linux kernel. A such generated mac address is always a locally administered address, of course.

    If I configure the master mac address with an enforced non locally administered address, it works like a charm.

    Many thanks, Franck, for your quick and helpful support.