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.

Linux/AM4377: PRU Ethernet issue in EtherCAT Master mode

Part Number: AM4377

Tool/software: Linux

Hi,

 I am having problems with the PRU-ICSS Ethernet firmware. I want to use the PRU as a EtherCAT master port but the ethernet firmware running inside the PRU locks up and doesn’t recover. I’ve had a quick look around this forum, and my issue is almost identical to this one : https://e2e.ti.com/support/arm/sitara_arm/f/791/p/551485/2019092

If I connect the EtherCAT slave directly to one of the PRU ports, the firmware inside the PRU locks up, stops triggering interrupts and cannot recover (even if I do “rmmod prueth” and “modprobe prueth”). I have to reboot the system for it to come up again.

If I try to connect the slave directly to the CPSW port instead, it works without any problem.

If I try to put an ethernet switch between the PRU port and the EtherCAT slave it works correctly. Perhaps that’s because the switch is dropping any invalid frames. It thus seems that an invalid frame received on the PRU causes its firmware to crash somehow.

Just to be clear : this is NOT an EtherCAT problem. This is an ethernet problem. More specifically, this is a PRU-ICSS Ethernet firmware problem.

Normally I would go ahead and fix it myself, but TI has not released the source code for the PRU Ethernet firmware, only binaries, so there’s really nothing I can do about it. Please fix this problem.

 Here’s the setup :

  • AM437x IDK board
    • Running latest SDK v3.02
    • IgH EtherCAT Master for Linux

  • Beckhoff EL9800 evaluation board
  • The software team have been notified. They will respond here.
  • Hi,
    can you check using latest SDK 3.3 (just released...)? This has a fix for the PRU issue mentioned in the other thread.

    Best regards,
  • Hi Frank,

    I just tested with the new SDK, and the problem is exactly the same.
    Also I checked the CRC of the PRU binary file against the previous SDK (3.2) and it is the same. Which means no change at all was made. I did the same thing for the prueth driver, and again it is the same.
    When you say this has been fixed, what is the source of that information ?
    Let me know if you need more information on my part, but we need to get this fixed…

    Thank you!

  • Hi,

    sorry, I missed you are on AM437x and the previous fix apparently was done for AM335x only. Now we need to check if your issue is the same as the one in the other thread and if that also affects AM437x. I will ask for some internal investigation.

    However from your side we would also need some data. So far the description does not give enough detail and evidence what is wrong. Could you provide a wireshark log for example?

    >>It thus seems that an invalid frame received on the PRU causes its firmware to crash somehow.

    Where would such invalid frames come from in your case?

    Regards,

  • Hi Frank,

    Well, I think I found the problem !
    While I was taking the Wireshark log that you were looking for, I noticed a bunch of ICMPv6 frames being transmitted along with the EtherCAT frames. We already noticed in the past that IPv6 frames and EtherCAT don't go well together, so I went ahead and disabled all IPv6 on the PRU interfaces, and it worked. I am now able to transmit and receive EtherCAT frames on the PRU interfaces without any problem.

    Here's what I did to disable IPv6 :
    (Temporary, lost at reboot) : # echo 1 > /proc/sys/net/ipv6/conf/eth1/disable_ipv6
    (Permanent) : # echo "net.ipv6.conf.eth0.disable_ipv6=1" >> /etc/sysctl.conf

    Perhaps that's something that should be investigated nonetheless because it is still weird that ICMPv6 frames cause the PRU to stop responding.

    Thank you