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.

MCU-PLUS-SDK-AM243X: MCU-PLUS-SDK-AM243X

Part Number: MCU-PLUS-SDK-AM243X

Tool/software:

Hi,

We are trying to implement a EtherCAT slave with 6SyncManager on the AM243x.

The Implementation is generally working. But we have a Problem with the Conformance Test.

As in the EtherCAT Slave Errata for PRU-ICSS-EtherCAT 01.00.10 (Firmware build x.4.243 (0x4f3)) mentioned:

Issue/ Failure Description:SDOCM00092510/PINDSW-47:

Single datagram accessing multiple FMMU mapped areas in a single slave will only update the data corresponding to first FMMU in datagram

This Issue leads to the Problem, that single Datagramms can't access to multiple SyncManagers(FMMUs). 

For the most EtherCAT Master there is a solution to the problem:

The entry  <Su SeparateSu = "true"/> solves the Problem by forcing the EtherCAT Master to split the PDOs in two different Datagrams.

But the Conformance Test Tool (CTT) of the EtherCAT Technology Group (ETG) doesn't split the Datagramms for the Conformance Test.

Therefor the Communication fails in the Test. The EtherCAT slave can not be certified.

Because of use of FSoE we are forced to certify our EtherCAT Slave in the Test facility of the ETG. 

My Question:

Is there a Solution for my Problem?

Has the PRU-ICSS EtherCAT Firmware ever been tested with the CTT? (with more than 4 SyncManager?)

  • Hi Stefan,

    Issue/ Failure Description:SDOCM00092510/PINDSW-47:

    Do let me know if this helps.

    Regards,
    Aaron

  • Hi Aaron,

    unfortunatly, the Releases 09.02.00.24 or 11.00.00.08 don't solve the problem completly.

    Yes, for datagramms in TwinCAT the problem disapeared.

    But with the ConformanceTestTool (CTT) the problem still exists.
    For EtherCAT Slaves the CTT is the only EtherCAT master that counts.

    As far as I can see, the main diffrence between CTT and Twincat is, that in TwinCAT the PDO datagramm  is embedded in other datagrams. In the CTT the PDO datagram is the only datagramm in the frame.

    As far as I can see the FMMU and SyncManager settings are the same.

    Regards

    Stefan

  • Hi Stefan,

    But with the ConformanceTestTool (CTT) the problem still exists.
    • May I know which test case is failing in your case. Could you share the complete wireshark logs for the failing scenario?
    • We have an internal example which utilizes 8 SyncManagers which require some more enhancements in the stack side which I'm currently working on. Once that is complete, I'll test the 8SM application with the CTT and observe for failures.

    Regards,
    Aaron

  • Hi Aaron,

    Every test of the CTT with SafeOP & OP state needed fails, because the Logical ReadWrite Datagram for the PDOs isn't working.

    The EtherCAT frame (with the LRW datagramm) sent back to the EtherCAT Master is damaged.

    conformanceTest_INIT_SAFEOP_FAIL_OP.pcapng

    This is a Wireshark file showing the problem.

    Regards,
    Stefan

  • Thank you Stefan for the details. We'll analyze the logs and try to reproduce this in our side.

    Regards,
    Aaron

  • On an additional note, can you make sure that the TX_START_DELAY is increased to 0x98 in the application? The access to multiple FMMU mapped areas using LRD/LWR commands from a single SubDevice needs increased latency and with the default value (0x48), the tests will fail. These can be verified by checking the value in MII_RT_TXCFG0 (0x300B2010) and MII_RT_TXCFG1 (0x300B2014):

    Also, is it possible to configure to use LRW in place of LRD/LWR which is more efficient for most of the use cases and test once? 

  • Hi Aaron,

    we will check and try the higher TX_Start_Delay time.

    What do you mean with: to configure to use LRW in place of LRD/LWR

    The CTT does already use LRW.
    If not differently set in the ESI File, every ECAT Configurator/Master i know uses LRW by default.

    Or do you want us to try it the other way round?
    LRD&LWR instead of LRW? We can try it, but I dont know if the ConformanceTestTool can do it.

    Regards,
    Stefan

  • Hi Stefan,

    What do you mean with: to configure to use LRW in place of LRD/LWR
    • I was referring to the fact that LRW command supports accessing multiple FMMU mapped areas which is more optimal with lower framing overhead. This was a workaround which was suggested earlier when PINDSW-47 was not fixed within EtherCAT firmware. 
  • Hi Aaron,

    I noticed today that the define ENABLE_MULTIPLE_SM_ACCESS_IN_SINGLE_DATAGRAM in tiescbsp.h is set to 0 per default. Enabling it changed the value of TX_START_DELAY to 0x98. There are also the defines TIESC_PROCESS_PATH_TX_DELAY_... and  TIESC_AUTOFORWARD_PATH_TX_DELAY_..., which we did also change to 0x98 for testing. However, we still do not reach OP with the Conformance Test (it still works with TwinCAT). The LRW frame seems to be cut. At the end, where the working counter should be, you see the CRC32 value of the frame. It is there, because the frame was cut.




    Do you have an idea why this happens?

    Kind regards,

    Martin

  • Hi Martin,

    I noticed today that the define ENABLE_MULTIPLE_SM_ACCESS_IN_SINGLE_DATAGRAM in tiescbsp.h is set to 0 per default
    • This is fine as the EtherCAt firmware dynamically configures the delay to 0x98 based on the number of FMMU entries and the access permission of these entries. 
    However, we still do not reach OP with the Conformance Test (it still works with TwinCAT). The LRW frame seems to be cut. At the end, where the working counter should be, you see the CRC32 value of the frame. It is there, because the frame was cut.
    • Thank you for the confirmation. The WKC of 31328 shows that there's some configuration mismatch in the processing path, which is forwarding incorrect values. We will check further on this.

    Regards,
    Aaron

  • Hi Aron,

    the abnormal WKC of 31328 is, as we think a missinterpretation of  Wireshark.

    Some data in the EtherCAT frame is missing. Wireshark is reading the first 2 Byte of the Ethernet CRC32(at the end of the Frame) as WorkingCounter data.

    Can you confirm this?

    Regards
    Stefan

  • Yes correct. There seems to be a mismatch in the datagram transmission after the PDO data has been processed, resulting in malformed packets. We are checking on this.

    Regards,
    Aaron