AM335x PRU-ICSS Ethernet fails as EtherCAT Master

Laurent Joye

Prodigy 170 points

Other Parts Discussed in Thread: AM3358, AM3359

I'm trying to use the PRU-ICSS as the ethernet interface for an EtherCAT master application.

The HW is the PCM-953 carrier board for phyCORE-AM335x of Phytec.

The Linux kernel PRU driver is coming from this repository:

git://git.phytec.de/linux-ti branch origin/v4.4.15-phy

Note that if I use the PRU-ICSS ethernet interface with some standard protocols (IP, TCP, DHCP, ...), it works without any failure.

In the case I use this interface for an EtherCAT master application (an EtherCAT frame is sent every 10ms), it doesn't work as expected. If I connect directly the PRU-ICSS to an EtherCAT slave through an Ethernet cable (crossed or not crossed), it doesn't work!!! There isn't any interrupt generated by the PRU firmware (checked with "cat /proc/interrupts"). It seems that the PRU firmware is frozen because there won't be anymore interrupt generated, even if I connect this interface to my computer to get an IP address though my DHCP server (what it works very well if I reboot my target!).

In the case I use the CPSW ethernet interface instead of the PRU-ICSS interface, it works very well. My EtherCAT master application runs without any failure.

In the case the EtherCAT master and the slave are connected trough a LAN switch, it also works very well (even with the PRU-ICSS)! 100 interrupts per seconds are generated.

I cannot find any explanation! According ethtool the interface is correctly configured (100 Mbit/s, full duplex). Note that the EtherCAT frame is sent and received back almost simultaneously (~1 microsecond delay).

Thanks for your help

over 9 years ago

0 Biser Gatchev-XID over 9 years ago

TI__Guru**** 393215 points

The EtherCAT experts have been notified. They will respond here.

0 David Zaucha over 9 years ago in reply to Biser Gatchev-XID

TI__Expert 7570 points

Hello Laurent

For the TI AM3358 ICE v2 EVM we recommend the 3S CODESYS EtherCAT Master as a RT Linux solution.
www.codesys.com/.../ethercat.html TI does not have an EtherCAT master solution.
You may want to check with 3S to see what support is available for the phyCORE-AM335x board.

David

0 Laurent Joye over 9 years ago in reply to David Zaucha

Prodigy 170 points

Hello David,

I don't await from TI any EtherCAT master solution. My problem has nothing to do with EtherCAT. It is a pure ethernet problem.

What I need from TI is simply a PRU ethernet firmware which behaves as another ethernet kernel driver.

My test:
I send an ethernet frame to an external device which reply the same frame except that the sender MAC address is not the same one. The delay between the request and the reply is very small ( < 1 microsecond).

Results:
In the case I send this frame over the CPSW interface, it works perfectly (I receive the replied frame as expected).
In the case I send this frame over the PRU interface, which is first connected to a LAN switch, it works also perfectly.
In the case I send this frame over the PRU interface connected directly to the external device, it doesn't work (no reply received and the PRU doesn't at all anymore).

Questions:
Is it possible for the PRU ethernet firmware to simultaneously send and receive ethernet frame?
Is there explanation about the different behavior between a standard ethernet kernel driver (CPSW) and the PRU firmware?
Is it possible that there is a bug in the PRU ethernet firmware?
Is it any chance that my test can work with the PRU?

Best regards

Laurent

0 David Zaucha over 9 years ago in reply to Laurent Joye

TI__Expert 7570 points

Laurent

Thank you for the additional information. I have tied in one of our Linux networking experts to assist in answering your questions.

David

0 Schuyler Patton over 9 years ago in reply to David Zaucha

TI__Mastermind 40390 points

Could you please provide a more explanation of what this test is trying to accomplish? If you are changing the sender MAC why not the dest MAC?

Answer to Questions:

- Is it possible for the PRU ethernet firmware to simultaneously send and receive ethernet frame? Yes, the firmware supports a full duplex link capability. This of course depends on the Ethernet PHY having been setup or auto-negotiated to a full duplex configuration.

- Is there explanation about the different behavior between a standard ethernet kernel driver (CPSW) and the PRU firmware? Not at the moment if I understand this setup correctly. The PRU is going to drop unicast packets that aren't addressed to it at the link layer. Which is why the question above of if the sender MAC is changed why not the destination MAC. It is surprising that the cpsw is accepting these packets. How is the reception being accounted for? What is the configuration of the cpsw, switch or dual mac? TI board? What application are you using to send the packets?

- Is it possible that there is a bug in the PRU ethernet firmware? Bugs are always a possibility but there are not any that we are aware of at the moment.

- Is it any chance that my test can work with the PRU? The test that you are performing will need to be understood better. There may be another way to test what you are trying to accomplish.

0 Frank Walzer over 9 years ago

TI__Mastermind 44306 points

Hi Laurent,

is this the same project as in your previous post?
e2e.ti.com/.../547917

Now there you said it is working. What case of above was that?
Can you let us know what EtherCAT master stack you are using?
We are usually not able to support 3P SW but we could have a look at some wireshark logs if you can produce that.
Maybe we can see something there.
It is a bit strange that the LAN switch gets the system to work. I would have assumed issues with that but not with a direct connection.

Concerning the PRU-ICSS EMAC driver you will need to ask phytec for support. They build their own Linux versions (based on ours I assume) but we don't know any details here. They may use some older version of Linux SDK.

Our reference designs for EtherCAT master do use the Acontis stack on TI-RTOS and we also have 3S/CoDeSys master working on Linux. So we know our Ethernet drivers are working.

Regards,

0 Laurent Joye over 9 years ago in reply to Frank Walzer

Prodigy 170 points

Thanks for your answers,

First of all, here are the responses to your questions:

The ethernet frame I send is a broadcast request (destination mac address ff:ff:ff:ff:ff:ff).

Ethtool shows me that the PHY did its work correctly (100Mbit/s and Full duplex in all of my test cases).

The CPSW driver is configured as dual mac.

I confirm that my problem concerns the same project as this post: e2e.ti.com/.../547917

The master EtherCAT stack is: Igh EtherCAT Master for Linux. But I don't wait help from TI about the EtherCAT master side.

Phytec, as TI, has its own Linux kernel source. Unfortunately! It will be much more simpler if you officially push your own ethernet driver on the official Linux kernel source tree (kernel.org). At the moment, I don't have any other choice to merge myself the sources of Phytec and TI! But if you have a look at the sources of Phytec, you will see that the sources for the prueth.[c|h] are the identical.

In attachment, I send the wireshark traces (request and reply with different sender MAC addrees).

ethernet-traces.pcapng.zip

0 Frank Walzer over 9 years ago in reply to Laurent Joye

TI__Mastermind 44306 points

Laurent,

Is this the good case of test? I see only one file in the zip...

Regards,

0 Laurent Joye over 9 years ago in reply to Frank Walzer

Prodigy 170 points

This file (to be opened with wireshark) shows the ethernet frame which is sent and replied (with change in the source MAC address). It shows also that the sender mac address is set to the broadcast address.

The question is: Should the PRU generate an interrupt with such case? The answer is yes with a LAN switch between the EtherCAT master and its slave, and the answer is no in the case the EtherCAT slave board is directly linked to the master.

In the meantime, I continue to make investigations. And I found with ethtool (option -S) that I have so many rxMisAlignmentFrames as awaited received frames. What does it means?

Many thanks in advance for your help

Laurent

0 Laurent Joye over 8 years ago in reply to Laurent Joye

Prodigy 170 points

Hello,

I'm still investigating around this problem.

I found the following procedure which systematically disturb the PRU ethernet firmware:
- Connect my EtherCAT slave module directly on the PRU network interface (eth2)
- Power ON the EtherCAT slave module and the TI AM3359 master board
- Send an ICMP request over the PRU network interface (this request will be looped back by my EtherCAT slave)
From this time, the PRU firmware won't work anymore! I can reconnect the PRU interface to a PC with a DHCP server and starting a DHCP client, but I never receive any IP address (what is working well if I reboot my infrastructure). The PRU won't generate any interrupts!

If I play the same scenario with CPSW interface (eth0) instead of the PRU, it works

Here are the traces of the scenario played over the PRU network interface (will block the PRU firmware!):

root@t1800:~# ethtool eth2
Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Speed: Unknown!
Duplex: Unknown! (255)
Port: MII
PHYAD: 2
Transceiver: external
Auto-negotiation: on
Link detected: no
root@t1800:~# ip link set eth2 up
net eth2: started
root@t1800:~# sleep 2
root@t1800:~# ethtool -S eth2
NIC statistics:
txBcast: 0
txMcast: 0
txUcast: 0
txOctets: 0
rxBcast: 0
rxMcast: 0
rxUcast: 0
rxOctets: 0
lateColl: 0
singleColl: 0
multiColl: 0
excessColl: 0
txHWQOverFlow: 0
rxMisAlignmentFrames: 0
stormPrevCounter: 0
macRxError: 0
SFDError: 0
defTx: 0
macTxError: 0
rxOverSizedFrames: 0
rxUnderSizedFrames: 0
rxCRCFrames: 0
droppedPackets: 0
tx64byte: 0
tx65_127byte: 0
tx128_255byte: 0
tx256_511byte: 0
tx512_1023byte: 0
tx1024byte: 0
rx64byte: 0
rx65_127byte: 0
rx128_255byte: 0
rx256_511byte: 0
rx512_1023byte: 0
rx1024byte: 0
sqeTestError: 0
root@t1800:~# ifconfig
eth1 Link encap:Ethernet HWaddr ec:ec:ec:ec:00:01
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

eth2 Link encap:Ethernet HWaddr ec:ec:ec:ec:00:02
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

root@t1800:~# ping -I eth2 -c 1 1.2.3.4
ping: Warning: source address might be selected on device other than eth2.
PING 1.2.3.4 (1.2.3.4) from 0.0.0.0 eth2: 56(84) bytes of data.
eth2: Link is Up - 100Mbps/Full - flow control off
From 127.0.0.1 icmp_seq=1 Destination Host Unreachable

--- 1.2.3.4 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

root@t1800:~# ifconfig
eth1 Link encap:Ethernet HWaddr ec:ec:ec:ec:00:01
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

eth2 Link encap:Ethernet HWaddr ec:ec:ec:ec:00:02
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:84 (84.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:112 (112.0 B) TX bytes:112 (112.0 B)

root@t1800:~# ethtool -S eth2
NIC statistics:
txBcast: 2
txMcast: 0
txUcast: 0
txOctets: 128
rxBcast: 0
rxMcast: 0
rxUcast: 0
rxOctets: 0
lateColl: 0
singleColl: 0
multiColl: 0
excessColl: 0
txHWQOverFlow: 0
rxMisAlignmentFrames: 0
stormPrevCounter: 0
macRxError: 2
SFDError: 1
defTx: 0
macTxError: 0
rxOverSizedFrames: 0
rxUnderSizedFrames: 0
rxCRCFrames: 0
droppedPackets: 0
tx64byte: 2
tx65_127byte: 0
tx128_255byte: 0
tx256_511byte: 0
tx512_1023byte: 0
tx1024byte: 0
rx64byte: 0
rx65_127byte: 0
rx128_255byte: 0
rx256_511byte: 0
rx512_1023byte: 0
rx1024byte: 0
sqeTestError: 0
root@t1800:~# ethtool eth2
Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 2
Transceiver: external
Auto-negotiation: on
Link detected: yes

Here are the traces of the scenario played over the CPSW network interface (no failure):

root@t1800:~# ethtool eth0
Settings for eth0:
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000000 (0)
Link detected: no
root@t1800:~# ip link set eth0 up
net eth0: initializing cpsw version 1.12 (0)
net eth0: initialized cpsw ale version 1.4
net eth0: phy found : id is : 0x7c0f1
8021q: adding VLAN 0 to HW filter on device eth0
root@t1800:~# sleep 2
root@t1800:~# ethtool -S eth0
NIC statistics:
Good Rx Frames: 0
Broadcast Rx Frames: 0
Multicast Rx Frames: 0
Pause Rx Frames: 0
Rx CRC Errors: 0
Rx Align/Code Errors: 0
Oversize Rx Frames: 0
Rx Jabbers: 0
Undersize (Short) Rx Frames: 0
Rx Fragments: 0
Rx Octets: 0
Good Tx Frames: 0
Broadcast Tx Frames: 0
Multicast Tx Frames: 0
Pause Tx Frames: 0
Deferred Tx Frames: 0
Collisions: 0
Single Collision Tx Frames: 0
Multiple Collision Tx Frames: 0
Excessive Collisions: 0
Late Collisions: 0
Tx Underrun: 0
Carrier Sense Errors: 0
Tx Octets: 0
Rx + Tx 64 Octet Frames: 0
Rx + Tx 65-127 Octet Frames: 0
Rx + Tx 128-255 Octet Frames: 0
Rx + Tx 256-511 Octet Frames: 0
Rx + Tx 512-1023 Octet Frames: 0
Rx + Tx 1024-Up Octet Frames: 0
Net Octets: 0
Rx Start of Frame Overruns: 0
Rx Middle of Frame Overruns: 0
Rx DMA Overruns: 0
Rx DMA chan: head_enqueue: 1
Rx DMA chan: tail_enqueue: 63
Rx DMA chan: pad_enqueue: 0
Rx DMA chan: misqueued: 0
Rx DMA chan: desc_alloc_fail: 0
Rx DMA chan: pad_alloc_fail: 0
Rx DMA chan: runt_receive_buf: 0
Rx DMA chan: runt_transmit_buf: 0
Rx DMA chan: empty_dequeue: 0
Rx DMA chan: busy_dequeue: 0
Rx DMA chan: good_dequeue: 0
Rx DMA chan: requeue: 0
Rx DMA chan: teardown_dequeue: 0
Tx DMA chan: head_enqueue: 0
Tx DMA chan: tail_enqueue: 0
Tx DMA chan: pad_enqueue: 0
Tx DMA chan: misqueued: 0
Tx DMA chan: desc_alloc_fail: 0
Tx DMA chan: pad_alloc_fail: 0
Tx DMA chan: runt_receive_buf: 0
Tx DMA chan: runt_transmit_buf: 0
Tx DMA chan: empty_dequeue: 0
Tx DMA chan: busy_dequeue: 0
Tx DMA chan: good_dequeue: 0
Tx DMA chan: requeue: 0
Tx DMA chan: teardown_dequeue: 0
root@t1800:~# ifconfig
eth0 Link encap:Ethernet HWaddr 68:c9:0b:24:5a:e7
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:174

eth1 Link encap:Ethernet HWaddr ec:ec:ec:ec:00:01
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

root@t1800:~# ping -I eth0 -c 1 1.2.3.4
ping: Warning: source address might be selected on device other than eth0.
PING 1.2.3.4 (1.2.3.4) from 0.0.0.0 eth0: 56(84) bytes of data.
cpsw 4a100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
From 127.0.0.1 icmp_seq=1 Destination Host Unreachable

--- 1.2.3.4 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

root@t1800:~# ifconfig
eth0 Link encap:Ethernet HWaddr 68:c9:0b:24:5a:e7
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:120 (120.0 B)
Interrupt:174

root@t1800:~# ethtool -S eth0
NIC statistics:
Good Rx Frames: 0
Broadcast Rx Frames: 0
Multicast Rx Frames: 0
Pause Rx Frames: 0
Rx CRC Errors: 0
Rx Align/Code Errors: 0
Oversize Rx Frames: 0
Rx Jabbers: 0
Undersize (Short) Rx Frames: 0
Rx Fragments: 2
Rx Octets: 0
Good Tx Frames: 2
Broadcast Tx Frames: 2
Multicast Tx Frames: 0
Pause Tx Frames: 0
Deferred Tx Frames: 0
Collisions: 0
Single Collision Tx Frames: 0
Multiple Collision Tx Frames: 0
Excessive Collisions: 0
Late Collisions: 0
Tx Underrun: 0
Carrier Sense Errors: 0
Tx Octets: 128
Rx + Tx 64 Octet Frames: 2
Rx + Tx 65-127 Octet Frames: 0
Rx + Tx 128-255 Octet Frames: 0
Rx + Tx 256-511 Octet Frames: 0
Rx + Tx 512-1023 Octet Frames: 0
Rx + Tx 1024-Up Octet Frames: 0
Net Octets: 156
Rx Start of Frame Overruns: 0
Rx Middle of Frame Overruns: 0
Rx DMA Overruns: 0
Rx DMA chan: head_enqueue: 1
Rx DMA chan: tail_enqueue: 63
Rx DMA chan: pad_enqueue: 0
Rx DMA chan: misqueued: 0
Rx DMA chan: desc_alloc_fail: 0
Rx DMA chan: pad_alloc_fail: 0
Rx DMA chan: runt_receive_buf: 0
Rx DMA chan: runt_transmit_buf: 0
Rx DMA chan: empty_dequeue: 0
Rx DMA chan: busy_dequeue: 0
Rx DMA chan: good_dequeue: 0
Rx DMA chan: requeue: 0
Rx DMA chan: teardown_dequeue: 0
Tx DMA chan: head_enqueue: 2
Tx DMA chan: tail_enqueue: 0
Tx DMA chan: pad_enqueue: 0
Tx DMA chan: misqueued: 0
Tx DMA chan: desc_alloc_fail: 0
Tx DMA chan: pad_alloc_fail: 0
Tx DMA chan: runt_receive_buf: 0
Tx DMA chan: runt_transmit_buf: 2
Tx DMA chan: empty_dequeue: 2
Tx DMA chan: busy_dequeue: 0
Tx DMA chan: good_dequeue: 2
Tx DMA chan: requeue: 2
Tx DMA chan: teardown_dequeue: 0
root@t1800:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000000 (0)

Link detected: yes

Questions:
- In the case my EtherCAT slave HW is guilty, according the above traces, what could be the reason?
- In any case, why is the PRU ethernet firmware not anymore reacting?

Many thanks in advance for helping me to solve this serious problem

0 Frank Walzer over 8 years ago in reply to Laurent Joye

TI__Mastermind 44306 points

Laurent,

that sounds like the problem can be triggered even with normal Ethernet packets. The stats show there is an RX error and we need to find out why. Apparently it screws up the PRU firmware somehow. In order to try to reproduce this I would assume we need the following info:

1) packet log (wireshark trace) of the ICMP test - it needs to show outgoing and returned frames
2) info on your EtherCAT device
3) details on software used (especially what was the basis for your PRU-ICSS EMAC driver) - otherwise we will only test with latest TI version in our Linux processor SDK

I assume this process is just to trigger the PRU issue. Otherwise I don't know why you would have ICMP packets on an EtherCAT network. I also do not assume it makes a lot of sense to run a port as EtherCAT master and then reconnect to normal Ethernet...

Regards,

0 Laurent Joye over 8 years ago in reply to Frank Walzer

Prodigy 170 points

Franz,

You're right. I'm playing this scenario (ICMP request over an EtherCAT slave controller) just to trigger the PRU issue.

I cannot transmit you the wireshark traces because this problem disappears once I put LAN switch between the master and the slave! I've tried to dump (with tcpdump) the returned frame by playing this scenario on the CPSW, but it seems the response is silently dropped. I think the EtherCAT slave controller should reflect back the ICMP request and the ethernet controller of the CPSW should drop it because the sender mac address is its own one.

My Linux kernel PRU ethernet driver is available on the branch "origin/v4.4.15-phy" of this git repository: git://git.phytec.de/linux-ti.

The firmware of the PRU-ICSS has be extracted from the root filesystem of the PROCESSOR-SDK-LINUX-AM335X located here: www.ti.com/tool/PROCESSOR-SDK-AM335x

0 Laurent Joye over 8 years ago in reply to Laurent Joye

Prodigy 170 points

... and my EtherCAT slave HW looks as follow:

0 Frank Walzer over 8 years ago in reply to Laurent Joye

TI__Mastermind 44306 points

Hi Laurent,

but we need to know how the packet looks like that is screwing up the firmware. Usually EtherCAT is not designed to support ICMP frames. Also we do not have your slave hardware as it seems to be special. We could try to debug using some Beckhoff slaves as they also have similar IP.

Anyway you will need a TAP (network trace tool such as Hilscher sells) to capture packets. Using a PC or switch in between will not work as they may drop any errored packets.

I will try to look into your Linux references next week and see if we can identify the PRU firmware versions. We can then try some basic tests with our ICSS EMAC setup and see how it reacts to ICMP packets. But I assume this to work as I have used that in standard Ethernet connect tests without any issues. I could use all kind of protocols based on TCP/IP (FTP, telnet, SCP,...) and usually the connected PC also sends all kind of packets in a standard Ethernet network config.

Regards,

0 Laurent Joye over 8 years ago in reply to Frank Walzer

Prodigy 170 points

I will probably order a network analyzer as you suggest.

Our final HW solution will be based on the reference of this Beckhoff document (EtherCAT slave controller Section I, download.beckhoff.com/.../ethercat_esc_datasheet_sec1_technology_2i2.pdf, chapter 5.14.2 ESC to Standard Ethernet MAC).

The idea is that the EtherCAT slave controller is connected directly to the MII interface of the PRU. There won't be any PHY in between. For this to be possible, I have to specify in the dts a fixed-link node as follow:

pruss_eth {
compatible = "ti,am3359-prueth";
pruss = <&pruss>;
sram = <&ocmcram_nocache>;
interrupt-parent = <&pruss_intc>;

pinctrl-0 = <&pruss_eth_default>;
pinctrl-names = "default";

pruss_emac0: ethernet-mii0 {
phy-mode = "mii";
interrupts = <20>, <22>;
interrupt-names = "rx", "tx";
/* Filled in by bootloader */
local-mac-address = [ec ec ec ec 00 01];
fixed-link {
speed = <100>;
full-duplex;
};
};

pruss_emac1: ethernet-mii1 {
phy-mode = "mii";
interrupts = <21>, <23>;
interrupt-names = "rx", "tx";
/* Filled in by bootloader */
local-mac-address = [ec ec ec ec 00 02];
fixed-link {
speed = <100>;
full-duplex;
};
};
};

This also implies to patch the PRU linux kernel driver as follow:

Index: ksrc/drivers/net/ethernet/ti/prueth.c
===================================================================
--- ksrc.orig/drivers/net/ethernet/ti/prueth.c
+++ ksrc/drivers/net/ethernet/ti/prueth.c
@@ -34,6 +34,7 @@
#include "icss_mii_rt.h"
#include "icss_switch.h"

+#define NO_PHY
#define PRUETH_MODULE_VERSION "0.2"
#define PRUETH_MODULE_DESCRIPTION "PRUSS Ethernet driver"

@@ -1531,12 +1532,30 @@ static int prueth_netdev_init(struct pru
}
ether_addr_copy(emac->mac_addr, ndev->dev_addr);

+#ifdef NO_PHY
+ emac->phy_node = of_parse_phandle(eth_node, "phy-handle", 0);
+ if (!emac->phy_node) {
+ if (!of_phy_is_fixed_link(eth_node)) {
+ dev_err(prueth->dev, "couldn't find fixed-link\n");
+ ret = -ENODEV;
+ goto free;
+ }
+ if (of_phy_register_fixed_link(eth_node) >= 0)
+ emac->phy_node = of_node_get(eth_node);
+ else {
+ dev_err(prueth->dev, "couldn't register fixed-link\n");
+ ret = -ENODEV;
+ goto free;
+ }
+ }
+#else
emac->phy_node = of_parse_phandle(eth_node, "phy-handle", 0);
if (!emac->phy_node) {
dev_err(prueth->dev, "couldn't find phy-handle\n");
ret = -ENODEV;
goto free;
}
+#endif

emac->phy_if = of_get_phy_mode(eth_node);
if (emac->phy_if < 0) {

Because there isn't no phy in this new HW, I tried to disable the autonegotiation (ethtool -s speed 100 duplex full autoneg off). But the PRU doesn't sent any character on the MII interface in this case!!

If I activate the autonegotiation, the PRU sent a first frame which is probably the autonegotiation frame, which is looped back from the EtherCAT slave controller. I don't know it the autonegotiation request could disturb the PRU firmare.

Questions:

Is the PRU firmware compatible with phy-less application?

Is it possible that the autonegotiation frame which is looped back can disturb the PRU firmware?

0 Frank Walzer over 8 years ago in reply to Laurent Joye

TI__Mastermind 44306 points

Laurent,
obviously that is a config we have not tested I assume. But it should not affect the PRU firmware as long as it does not interact with the phy (which will be missing in your case). Autonegotiation is a process done between two phys. The EMAC does not see 'packets' or however that is done from such an operation. The only thing that I would assume to see on the ARM side is a link status event (received through MDIO interface).
I have no details on the Linux driver but if that reacts to MDIO events and they are not coming because you disabled autonegotiation it may affect the packet operation. Usually our firmware gets a flag from ARM driver if the link is down. That prevents PRU from sending packets even if there is no link.
In the working case you should see something like ARP packets from the TCP stack. Yes, a network trace/capture tool (you don't need an expensive network analyzer here) will be good.

Regards,

0 Laurent Joye over 8 years ago in reply to Frank Walzer

Prodigy 170 points

Franz,

We rent a logic analyzer to measure the signals on the MII interface between the PRU and the ET1200 (EtherCAT slave controller). Note that what is transmitted is looped back by the ET1200 (the sender mac address is changed in case of an EtherCAT frame only).

We've observed that the first frame sent by the PRU is not conformed to an ethernet frame. The next sent frames are conformed. Because in our case all what is sent by the PRU is also received back, the first unconformed ethernet frame is also received by the PRU. It seems that the PRU firmware doesn't react anymore once it has received this unconformed frame.

In the joined traces, coming from the logic analyzer, you will see 3 frames:

A conform EtherCAT frame (not the first one) sent back to the PRU. Note that the MSByte of the source MAC address has been changed by the ET1200 (0xec to 0xee)
The first frame sent by the PRU. The PRU sent only what is surrounded by a frame. In this case, it should be a EtherCAT frame. But the preamble bytes and the delimiter flag are missing! Note that also the last bytes are missing!
The first frame sent by the PRU. The PRU sent only what is surrounded by a frame. In this case, it should be a ICMP frame. But the preamble bytes and the delimiter flag are missing! Note that also the last bytes are missing!

Do you have any explanation why the PRU doesn't sent a first conform frame?

test3.pdf

0 Frank Walzer over 8 years ago in reply to Laurent Joye

TI__Mastermind 44306 points

Hi Laurent,

thanks for the additional info. I will now take that to our engineering level as I have no idea how this can happen. Usually the frame pre-amble is auto generated by the PRU hardware as it is constant anyway. Why this is not the case here I have no clue. Also I can't say what happens if there is a frame received that has no pre-amble. Not sure if I could even generate such a frame with standard equipment.

It may take a few days until we get more here as I assume this needs some extra work and probably planning.

Is there anyway you could avoid such a situation? E.g. ping on an EtherCAT network is not required. Is your normal EtherCAT application working?

Regards,

0 Frank Walzer over 8 years ago in reply to Frank Walzer

TI__Mastermind 44306 points

Hi Laurent,

I discussed the issue with a PRU programmer. Indeed auto generation of preamble is a PRU HW feature that can be disabled. Normally this should be enabled by the init code of ICSS EMAC driver. PRU just copies frame data into TX FIFO. So in your case there is either some init code missing or something overwrites the initialization.

So I suggest to compare your custom Linux ICSS driver with the version we provide as part of Linux Processor SDK. Are there any differences?

Regards,

0 Laurent Joye over 8 years ago in reply to Frank Walzer

Prodigy 170 points

If I test the PRU with my EtherCAT application, then I have the same symptom. The first EtherCAT frame is not conform and the PRU does not work anymore. As already said, in the case there is LAN switch between the Master and the Slave, it works (ICMP or EtherCAT).

0 Frank Walzer over 8 years ago in reply to Laurent Joye

TI__Mastermind 44306 points

Laurent,

only the first frame is missing preamble?
My assumption is that the LAN switch does correctly remove any bad frames. And if there is only an issue with first frame then the system just works.
However still the question is there why first frame is bad...
I have asked our engineering to try to generate a frame with missing preamble and try to receive this. If we can do this we should be able to debug why PRU locks up on such a frame. It should also just drop it of course.

By the way what is the EtherCAT master you are using? Does it do any special config or init of the ICSS EMAC?

Regards,

0 Laurent Joye over 8 years ago in reply to Frank Walzer

Prodigy 170 points

The PRU firmware I use is the latest one (extracted from your SDK: software-dl.ti.com/.../index_FDS.html, version 3.1.0.6).
I've also checked that these kernel driver files are identical (and they are) to those available in your latest SDK:
drivers/net/ethernet/ti/prueth.c
drivers/net/ethernet/ti/prueth.h
drivers/net/ethernet/ti/icss_mii_rt.h
drivers/net/ethernet/ti/icss_switch.h

0 Laurent Joye over 8 years ago in reply to Frank Walzer

Prodigy 170 points

The EtherCAT master stack I use is: etherlab.org/.../
I use only the generic device driver, meaning that the code the related ethernet driver is not touched.

0 Laurent Joye over 8 years ago in reply to Frank Walzer

Prodigy 170 points

Frank,

I've received some EtherCAT modules of Beckhoff and I did the same tests. With Beckhoff modules it works even without LAN switch.

Therefore we did some more investigations around our own EtherCAT slave HW. And we found the failure which was producing some malformed ethernet frames. A pull down resistor was missing the TX_Enable signal of the MII interface. Because there isn't any PHY, the MII interface is directly connected to the EtherCAT slave controller. At the startup, the TY_Enable become active for a short time, and it was the cause of our problems. Thanks for your help.

Even with the Beckhoff modules, if I sent a ICMP request (I know this is an non sense, but just to provoke a malformed ethernet frame!), the PRU firmware gets frozen. By a sending a non EtherCAT frame, the EtherCAT slave controller will simply partially retransmit the first part of the ethernet frame. This shall be considered, by the PRU firmware, as a malformed data frame and, in this case, this frame shall be discarded.

Could you please inform me when this PRU firmware could be fixed? It is for me a high priority, because our system shall support erroneous data frame also.

0 Frank Walzer over 8 years ago in reply to Laurent Joye

TI__Mastermind 44306 points

Hi Laurent,

sorry for the late reply. I was out a couple of days for a major fair.
Now your issue is reported internally and the team is working on reproducing the issue. Once this is done we can work on a fix and integrate into some future release. Sorry, that is all I have for now.

Regards,

0 Louis-Joseph over 8 years ago in reply to Frank Walzer

Prodigy 60 points

Hi Frank,

We may have the same issue here, we are able to have the master SOEM communicate via a Switch, but not connected directly to the Ethercat slave. Does this issue have been solved in the PRU firmware, or do you know when it would be solved?

Thanks,

0 Frank Walzer over 8 years ago in reply to Louis-Joseph

TI__Mastermind 44306 points

Hi Louis-Joseph,

I would like to ask you to open a new thread for your issue. Until we really know it is the same we treat all customer issues as unique.
Above issue is internally reported and reproduced (however only with AM335x and Linux while other SoC and OS configs don't see the issue). I don't have a schedule for a fix right now.

Anyway I need to question your setup. What is the purpose of using a switch within an EtherCAT chain? Don't you think it will destroy your EtherCAT packets?

regards,

0 Frank Walzer over 8 years ago in reply to Frank Walzer

TI__Mastermind 44306 points

Hi Laurent,

we just released Processor SDK 3.3. This has a fix for this issue.

Best regards,

Processors

Processors forum

AM335x PRU-ICSS Ethernet fails as EtherCAT Master