AM335x Industrial SDK v1.0.0.7 Daisy Chain Cable Connect/Disconnect Issue w/ EtherCAT Firmware / PRU-ICSS

Jonathan Marrs

Hi,

I have discovered an issue with connecting and disconnecting the cable between two EtherCAT slaves in a daisy-chained network. I am using the AM335x Industrial SDK v1.0.0.7.

The daisy chain includes a cable from the EtherCAT Master (TwinCAT) to Port 0 of EtherCAT Slave A, and a cable from Port 1 of EtherCAT Slave A to Port 0 of EtherCAT Slave B.

The issue occurs while both slaves are in OP mode and I connect and disconnect (Hot Connect) the cable between Port 1 of EtherCAT Slave A and Port 0 of EtherCAT Slave B. Upon disconnecting and reconnecting the cable, Slave B will usually go back to OP mode but will sometimes fail to go back to OP mode... it will sometimes remain in an Init error state. This happens if i disconnect and reconnect either Port 1 of Slave A, or Port 0 of Slave B. If I keep unplugging and plugging the cable, eventually Slave B goes back to OP mode, but it is very random.

Slave B should always go back to Op mode when the cable is reconnected, since that is the behaviour of slaves with the ET1100 EtherCAT Slave Controller (ESC).

Here is a diagram of the Hot Connect issue:

If I disconnect and reconnect the cable between the EtherCAT Master and Port 0 of EtherCAT Slave A, both EtherCAT Slave A and EtherCAT Slave B will always go back to OP mode when the cable is reconnected. So this Hot Connect issue might have something to do with the handling of Port 1 in the EtherCAT Firmware / EtherCAT Slave Controller (ESC) / PRU-ICSS of the AM335x.

Thanks.

over 12 years ago

0 PratheeshGangadhar over 12 years ago

TI__Mastermind 47801 points

Hi,

We are trying to reproduce this, can you please share following details

> Are you using ICE or IDK or your own h/w ?

> SM sync or DC sync (has a known issue during hot connect)

> Revision of AM335x used in the EVMs ? ( PG1.x or PG2.x)

Also please try 1.0.0.8 which is the latest release for EtherCAT and let us know the status.

0 fmdhr over 12 years ago in reply to PratheeshGangadhar

Expert 1530 points

Hi,

I think this is the same issue we discussed last year, see http://e2e.ti.com/support/arm/sitara_arm/f/791/p/188991/681435. Am I right?

Frank M.

0 Jonathan Marrs over 12 years ago in reply to PratheeshGangadhar

Intellectual 555 points

I am using the ICE.

Both slaves are in FreeRun/SM Sync mode.

Both ICE boards have the PG1.0 AM335x.

I initially discovered this Hot Connect issue when using my own board, which includes the PG1.0 AM335x and ISDK 1.0.0.7.

It seems that this Hot Connect issue occurs more easily to my board, perhaps because my process data is much larger than that of the ICE.

I was also able to observe this issue on the ICE, but it usually takes many more iterations of unplugging and plugging the cable before the issue appears.

I have captured some wireshark logs of the issue. Some logs are of the ICE and some logs are from my board. In each log, I stopped logging a few seconds after the issue occured (when the second slave could not reconnect upon plugging the cable back in).

Here are some wireshark logs of the ICE. I could only really capture one occurance at the end of the log because it occurs less frequently on the ICE:

Here are some wireshark logs of the same issue on my board. In some cases I was able to capture multiple occurances in one log file because the issue usually occurs after fewer attempts:

1881.t30_port1issue.zip

Regards

0 Jonathan Marrs over 12 years ago in reply to Jonathan Marrs

Intellectual 555 points

It looks like the Wireshark logs from the ICE disappeard from my last post. Here they are again:

1300.ice_port1issue.zip

0 Jonathan Marrs over 12 years ago in reply to fmdhr

Intellectual 555 points

fmdhr said:

I think this is the same issue we discussed last year, see http://e2e.ti.com/support/arm/sitara_arm/f/791/p/188991/681435. Am I right?

Hi Frank,

No, I do not think this is exactly the same issue. It is similar though, and may be related to the issue you reference.

I think in the issue you are talking about, Slave A always needed to be reset after Slave B was hot connected to Slave A, in order for Slave B to be detected and go to Op mode.

That issue was fixed by a previous release of the SDK (I think in SDK 1.0.0.6?).

This is a slightly different issue. Slave A no longer has to be reset every time Slave B is hot connected to it in a daisy chain. In newer releases of the SDK, Slave B will usually go to Op mode automatically after it is connected to Slave A. The issue is that this does not always happen. Once in a while, Slave B does not automatically go to Op mode, and I need to unplug and plug the cable again for it to go to Op mode, or I need to cycle the slaves from Init to Op, or I need to reset Slave A. So it looks like somehow the ESC of Slave A is entering some strange state for the handling of Port 1.

0 PratheeshGangadhar over 12 years ago in reply to Jonathan Marrs

TI__Mastermind 47801 points

Hi,

This issue is addressed in 1.0.0.9 release - http://processors.wiki.ti.com/index.php/AM335x_SYSBIOS_Industrial_SDK_01.00.00.09_Release_Notes#Fixed_In_This_Release

SDOCM00101828, SDOCM00100692

The release can be accessed here, : http://downloads.ti.com/sitara_indus/esd/AM335x_SYSBIOS_Industrial_SDK/latest/index_FDS.html

Processors

Processors forum

AM335x Industrial SDK v1.0.0.7 Daisy Chain Cable Connect/Disconnect Issue w/ EtherCAT Firmware / PRU-ICSS