AM2432: Unable to transition from SafeOP to OP

Hi Kanae,

Kanae said:

-SDK: Ind_comms_sdk_am243x_09_00_00_03
-Master: Linux IGH EtherCAT Master (installed on a standard PC)
・Master Start → Slave Start ... Failed
・Slave Start → Master Start ・・・ Failed

This failure is expected as non-interleaved LRW access was not supported on the firmware available in 09.00 SDK. The corresponding support was enabled only in SDK v09.02.00.24.

Kanae said:

・Slave Start → Master Start ・・・ Failed. Occasionally successful

Please provide the wireshark logs for the failing scenario along with the ICSS Memory Dump, that is,

• From 0x30000000 to 0x30040000 if you're using ICSSG0 instance.
• From 0x30080000 to 0x300C0000 if you're using ICSSG1 instance.

I suspect if the TX_START_DELAY (TIESC_PORT0_TX_DELAY_200_MHZ_CLOCK in tiescbsp.c) is increased for non-interleaved LRW access done by IGH. To give a background, the default value for TIESC_PORT0_TX_DELAY_200_MHZ_CLOCK is 0x48, which corresponds to 360ns. For non-interleaved LRW access made by the MainDevice (like IgH and SOEM), the TIESC_PORT0_TX_DELAY_200_MHZ_CLOCK needs to be increased to 0x98 (which corresponds to 760ns) to take care of the timing constraints.

This delay compensation is dynamically done through EtherCAT firmware based on the FMMU configuration set by the master. There can be cases were the firmware bypasses this check, due to some unforeseen miss in the firmware logic.

You can share the above mentioned logs and memory dump to confirm if the timing is the issue here. Additionally, you can enable the following macro to increase the delay within the application in ind_comms_sdk_am243x_11_00_00_08\source\industrial_comms\ethercat_slave\icss_fwhal\tiescbsp.h and see if this helps:

/*Single datagram accessing contiguous multiple FMMU mapped areas in  a single slave for process data
is supported now by TI ESC firmware.
Process path latency in TI ESC is high when this support is active
For specific use cases (4SM with 3 FMMUs or multiple FMMUs (in a given ESC) are not accessed in a single datagram)
process path latency improvement can be achieved by disabling below define */

#define ENABLE_MULTIPLE_SM_ACCESS_IN_SINGLE_DATAGRAM     1

Kanae said:

If possible, I would prefer to resolve this while keeping the SDK version
as Ind_comms_sdk_am243x_09_00_00_03 and would appreciate a solution using the old version.

Yes this is possible. You can pick the latest EtherCAT firmware headers (source\industrial_comms\ethercat_slave\icss_fwhal\firmware\) from SDK 11.00.00.08 and use it in your application. More details here: EtherCAT Firmware Migration guide.

Regards,
Aaron

Hi Aaron,

Thank you for your support.

I have received the operational verification results from my customer.

Changing TX_START_DELAY from the default 0x48 (360ns) to 0x98 (760ns)
showed improvement compared to the results I previously reported.

Before change) Slave start → Master start ... Failed. Occasionally succeeded.
After change) 　Slave start → Master start ...Succeeded. Occasionally failed.

Failures are still observed, but the success rate has significantly increased.

The file you provided is likely the ICSS demo sample program.
However, the customer is using the Beckhoff SSC demo sample program.
Could you please provide the modified sections using this sample program?

The above verification was performed by directly modifying register values
via the debugger, not using the sample program.

Best Regards,
Kanae

Kanae,

Kanae said:

Failures are still observed, but the success rate has significantly increased.

Glad to hear the failure has improved. I'm still not sure why the firmware is behaving differently in Master Start → Slave Start and Slave Start → Master Start. The TX_START_DELAY seems to be taken care by the firmware in the successful scenario.

As mentioned earlier, could you provide the wireshark logs and the ICSS Memory dump for the failing scenario? 

Kanae said:

The above verification was performed by directly modifying register values
via the debugger, not using the sample program.

Make sure this register (0x0E10) is programmed before PRU cores start running.

Kanae said:

However, the customer is using the Beckhoff SSC demo sample program.

The suggestion provided is for EtherCAT SubDevice Beckhoff SSC Demo. source\industrial_comms\ethercat_slave\icss_fwhal\tiescbsp.h is being used by EtherCAT SubDevice Beckhoff SSC Demo only. Also make sure the customer is using the latest EtherCAT firmware, that is, from v11.00.00.08. Customer SDK can be an older version but integrate the latest firmware to the customer project.

Regards,
Aaron