AM3359: EtherCAT: Busy bit not reset when reading SII

Hi Chris,

Chris S said:

where the reset of the busy bit happens: In the SSC or in the PRU firmware? And what triggers the reset?

• The ESI EEPROM busy bit is cleared by the EtherCAT PRU firmware. This is done by the firmware based on the command sent by the host using the bsp_send_command_to_firmware() where bsp_pruss_cmd_intfc_write_word() writes to the DMEM and the firmware reads from that memory and acknowledges the command.
• One possible issue is that the sending command to the firmware is taking longer than expected?

Is this something we can reproduce from our side? Are you trying the default example provided from TI or is it a custom application?

Regards,
Aaron

Hi Aaron,

thanks a lot for your fast reply! This is a custom application on Linux (which I'm aware you do not officially support), so unfortunately I cannot provide a reproduction on an official TI example.

As per your advice, we've studied the code and see the following call chain:

EEPROM_CommandHandler(..) in ecatappl.c: at the end, this calls
-> HW_EscWriteWord(..) in tieschw.c
-> bsp_pdi_write_indication(..) in tiescbsp.c
-> bsp_eeprom_emulation_command_ack(..)
-> bsp_send_command_to_firmware(CMD_DL_USER_EEPROM_CMD_ACK, 0, 0)

Is it this last call that will cause the busy bit to clear? And could you maybe elaborate on how you think this might be taking longer than expected?

Relatedly, at which point would the busy bit be set? Is this done by the PRU firmware without host intervention upon receiving an Ethercat write to SII control/status register 0x502 with the ReadOperation bit set? We're wondering if maybe EEPROM_CommandHandler is called too late for some reason.

Thanks in advance for any insights!

Hi Chris,

Chris S said:

Is it this last call that will cause the busy bit to clear?

• Yes correct, the last call with CMD_DL_USER_EEPROM_CMD_ACK command will be acknowledged by the firmware to clear the busy bit.

Chris S said:

And could you maybe elaborate on how you think this might be taking longer than expected?

• My statement was based on the fact that the firmware will clear the bit depending on when the CMD_DL_USER_EEPROM_CMD_ACK is sent by the host. Since the firmware is dependent on this command, looks like this is triggered later than expected, thus resulting in firmware to miss out on the timeout window.

Chris S said:

Relatedly, at which point would the busy bit be set? Is this done by the PRU firmware without host intervention upon receiving an Ethercat write to SII control/status register 0x502 with the ReadOperation bit set?

• I'll have to check on this. Give me sometime while I check on this and get back to you.

Chris S said:

We're wondering if maybe EEPROM_CommandHandler is called too late for some reason.

• That can also be a possibility. Additionally, is it possible to try a different EtherCAT MainDevice to see if this issue is dependent on SOEM flow? If we have a working scenario, then we can profile the timing here with the working scenarios.

Regards,
Aaron

I'll have to check on this. Give me sometime while I check on this and get back to you.

Thanks, Aaron, I appreciate that. Knowing when the busy bit is set might help us locate the delay between there and the sending of CMD_DL_USER_EEPROM_CMD_ACK.

Additionally, is it possible to try a different EtherCAT MainDevice to see if this issue is dependent on SOEM flow?

I've tried reading the EEPROM from the EtherCAT Conformance Test Tool and could not reproduce the problem. The issue may well depend on the specific flow from SOEM. So unfortunately, I can not provide a clear working scenario yet.

We've also tried TwinCAT as a MainDevice but here we're seeing a different (but maybe related?) problem. The ESC fails to return the Data Link Layer Loop Status (ESC register 0x111), i.e. the device does not increase the working counter.

Here's a frame with two identical read commands, one addressed to a Beckhoff terminal and one to our device:

Other registers are returned fine, as seen in the third datagram.

After successfully reading register 0x111 from the terminal, TwinCAT will proceed to bring that SubDevice into PREOP state, but for our device it stops at this point.

Would you expect TI PRU-ICSS-ETHERCAT-SLAVE  01_00_10_00 to support this register?

Hi Chris,

Please expect a reply by EOD Friday as it is a holiday here today.

Chris S said:

Would you expect TI PRU-ICSS-ETHERCAT-SLAVE  01_00_10_00 to support this register?

• Yes this register is vital to communicate the DL Status with the EtherCAT MDevice. I haven't seen scenarios where the firmware doesn't acknowledge this Register offset. Let me check if there's any dependency on the host side for this Register to be acknowledged (which I don't expect to) so that the SOEM issue can also be similar to this issue. 
• Also could you share the complete Wireshark logs for the TwinCAT issue?

Regards,
Aaron

Hi Aaron,

I'm attaching a Wireshark log taken while restarting the TwinCAT master. The cabling is this:

    |Master| -- |Beckhoff EK1814| -- |AM3359 device|

In frame 178, the master sets a configured station address for the Beckhoff terminal and then proceeds to bring it up. For our device, there are just repeated failed attempts to read register 0x111.

twincat_master_restart.zip

Thanks Chris for the logs. I'll analyze this and get back.

Regards,
Aaron

Context: follow-up in https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1511164/am3359-am335x

Hi Chris,

Chris S said:

Knowing when the busy bit is set might help us locate the delay between there and the sending of CMD_DL_USER_EEPROM_CMD_ACK.

• The busy bit (bit15) of EEPROM Control/Status is set when the MainDevice issues a write to the same register (Register 0x0502 or 0x0503 - EEPROM Control/Status).

Regards,
Aaron

Hi Chris,

Chris S said:

In frame 178, the master sets a configured station address for the Beckhoff terminal and then proceeds to bring it up. For our device, there are just repeated failed attempts to read register 0x111.

• Could you share the ICSS Memory dump when this issue occurs? From the firmware point of view, I don't see any special handling when the MainDevice reads from this register.

Regards,
Aaron 

Hi Aaron,

The busy bit (bit15) of EEPROM Control/Status is set when the MainDevice issues a write to the same register (Register 0x0502 or 0x0503 - EEPROM Control/Status).

Excellent, this will certainly help us locate the error better.

Could you share the ICSS Memory dump when this issue occurs?

We're unfortunately still working on preparing register and memory dumps. I'll yet you know as soon as we have these.

Sure Chris.

Regards,
Aaron