• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 3348 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM3357: EtherCAT ESC operation

Sh.Sasaki
Guru 13625 points

Part Number: AM3357

Hi all,

Are "RX Error Counter" and "Forwarded RX Error Counter" of TI ESC the same as the specifications of the following links?

https://www.pcb-3d.com/wordpress/wp-content/uploads/BGA128C80P12X12_1000X1000X120_JEDEC_MO-205_Beckhoff_10mmX10mm_TFBGA_128balls_ET1100.pdf

p.I-85 : 14.2 Errors and Forwarded Errors

The ESCs distinguish errors initially detected by an ESC and forwarded errors detected by a previous ESC. This is useful for error location when interpreting the RX Error/Forwarded RX Error counters. The first device detecting an error (e.g., a CRC error or an RX Error of the physical layer), will discard register operations and count a port error (0x0300-0x0307). The outgoing frame gets a special marking, consisting of one extra nibble added after the (invalid) CRC. A device receiving a frame with a CRC error and an additional nibble will also discard register operations, but it will count one Forwarded RX Error instead of a normal port error. NOTE: A forwarded error is sometimes called “green error”, the initial error is sometimes called “red error”. A physical layer RX Error is always a “red error”, because it could not have been forwarded.

Best regards,

Sasaki

  • 0
    TI__Guru**** 393215 points
    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Expert 7570 points

    Hi Saskai

    For any description of ESC register function we recommend going to ETG/ Beckhoff documentation and their forum.

    We have a link for some of this information in the Sitara FAQ at http://processors.wiki.ti.com/index.php/FAQ_Sitara_Industrial#Where_to_find_additional_information_on_TI.E2.80.99s_Sitara_processor_EtherCAT_Slave_Implementation 

    Is the error condition that you are seeing occur when the an error is occurring in the when the Error frame (without SFD) arrives at the IN or the OUT port of a slave?

     David

  • 0 in reply to David Zaucha
    Guru 13625 points

    Hi David-san,

    Thank you for your support.

    David Zaucha said:

    Is the error condition that you are seeing occur when the an error is occurring in the when the Error frame (without SFD) arrives at the IN or the OUT port of a slave?

    Yes. When an error frame arrives, the Forward RX Err of the IN port remains 0,
    The Forward RX Err of Out port was counting up.
    Is this behavior correct?
    I would like to know why Forward RX Err does not count up at the IN port.

    Yellow block is Forward RX Error.

    Best regards,

    Sasaki

  • 0 in reply to Sh.Sasaki
    TI__Expert 7570 points
    Hi Sasaki

    To help us understand where is the error source - could we get a couple of additional pieces of information?
    The error counter values for all the slaves (0x300-0x30C ESC registers) ?
    If you have a passive sniffer like Hilscher netanalyzer or Beckhoff TAP, could you provide a wireshark log?

    David
  • 0 in reply to David Zaucha
    Guru 13625 points

    Hi David-san,

    Thank you for your reply.

    I report additional information I got from my customers.

    0804.log.zip

    Please advise me if you find something from this log.

    Best regards,

    Sasak

  • 0 in reply to Sh.Sasaki
    TI__Expert 7570 points
    Hi Sask

    We notice that in the first file log_verification1.pcapng, after a certain point (frame 148), none of the frames return back to master.
    In the second file, from the very beginning, none of the frames return back to the master. It looks from the logs that one of the boards on the forward path is not forwarding the frames at all leading to frame drop.

    To help us understand the data -
    1. Are the two log files taken during the same test or all the boards were reset before taking the second log?

    2. What are the error counter values on each board when you see this issue?

    3. What version of the EtherCAT driver and firmware are they using?
    For example are you using PRU-ICSS-ETHERCAT-SLAVE 01_00_05_00 with the firmware that came with this release
    As described in the release notes - this release uses firmware build 1.4.236 .
    Platform Build Firmware Header location
    AM335x, AMIC11x 1.4.236 protocols\ethercat_slave\firmware\v1.0

    4.Does this issue happens always or in a specific condition?

    4.1. if yes then what is that condition?

    4.2. What are the steps to create (or reproduce) this condition?

    David
  • 0 in reply to David Zaucha
    Guru 13625 points

    Hi David-san,

    Thank you for your support.

    I will list the information I got from my customers.

    David Zaucha said:

    1. Are the two log files taken during the same test or all the boards were reset before taking the second log?

    There was a mistake in the information described the other day. The following is the problem now.

    The customer tested in the above connection state.

    And the log acquired in this connection state is log1.zip.

    log1.zip

    David Zaucha said:

    2. What are the error counter values on each board when you see this issue?

    The error counter value is as follows.

    Number of error occurrences   x < y

    ECAT Processing Unit One Error Counter register per 1ESC. Not for each port.
    Since the ECAT Processing Unit Error Counter counts when receiving packets other than ECAT, it is presumed that this is the problem of Forward RX Err Counter.

    David Zaucha said:

    3. What version of the EtherCAT driver and firmware are they using?
    For example are you using PRU-ICSS-ETHERCAT-SLAVE 01_00_05_00 with the firmware that came with this release 
    As described in the release notes - this release uses firmware build 1.4.236 .
    Platform Build Firmware Header location 
    AM335x, AMIC11x 1.4.236 protocols\ethercat_slave\firmware\v1.0 

    　EtherCAT Slave Stack：V5.11

    　TI Pruss：2.1.1.2

    David Zaucha said:

    4.Does this issue happens always or in a specific condition?

    It always occurs.

    David Zaucha said:

    4.1. if yes then what is that condition? 

    It always occurs in any state.

    Best regards,

    Sasaki

  • 0 in reply to Sh.Sasaki
    TI__Expert 7570 points

    Hi Saski

    I am sorry - I was not clear in one of the questions.

    1) What version of the EtherCAT slave software is your customer using?
    - for example is it

    PRU-ICSS-ETHERCAT-SLAVE 01_00_04_00 

    PRU-ICSS-ETHERCAT-SLAVE 01_00_05_00 

    SYSBIOSSDK-IND-SITARA v02.01.01.02

    SYSBIOSSDK-IND-SITARA v02.01.03.02

    or is it another version?

    2) Are they using the PRU firmware that is contained in that release or are they using firmware from a different release? 

    David