• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 33 subscribers
  • Views 197 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.

AM2432: When could drive miss ECAT PDI signal

Mu Logan
Prodigy 120 points
Part Number: AM2432


Tool/software:

Hi Ti experts,

We experienced random packet lose phenomenon in our application. We checked PDI and SYNC0 arrival time in normal case and packet lose case. And it’s found that PDI is about 90 us before SYNC0 in normal case, which is a happy condition. But when packet lose happens, the PDI is lost in one cycle. *cycle time 4ms.

The following are recordings of Sync0 time - PDI arrival time. You can see the time difference is 4000us larger when issue happens. It means that PDI of one cycle is not triggered.

We want to know when this phenomenon (PDI doesn't arrive) could happen? we are sure it's not MC issue, since other slaves doesn't face this issue at same moment.

Our current implementation uses Sync 0 and PDI interruptions. Also we have a cyclic interrupt whose priority is higher for both sync 0 and pdi.

We suspect some operation in cyclic interrupt  cleans the PDI ISR flag. Is there some ECAT register can reflect if PDI arrives physically?

  • 0
    TI__Mastermind 48171 points

    When packet loss occurs then SM write interrupt can't occur? Hence PDI ISR which is dependent on AL Event Request and AL Event Mask configuration would not assert. This is expected behavior of ESC

  • 0 in reply to PratheeshGangadhar
    Intellectual 870 points

    Hi Pratheesh,

    The issue we met is that when the drive detects a frame loss, due to pdi_isr not triggered. However there are few drives after the fault drive which detects less. 

    If the issue is caused at physcal layer, say crc error, then all of them should detect same number of frame loss, and same as RX error counter register (ESC reg 0x300:0x301 and 0x302:0x303). 

    In the network, there are 170+ nodes. 9 drives are connected to one port of a spliter, the first is XMC4800 which detected no frame loss, the rest are AM2432s. The first AM2432 detected 25 frame loss, second is 27, ..., the last is 5.

    For RX error counter, in port of the first drive is 11, out port is 0. For the rest drives, RX counter is 0 for both IN and OUT port. 

    In one of other port at customers' side, the RX error counter is consistent that first 10 drives, all of them are INOVANCE, is 7 for IN port and 54 for OUT port. The 11th drive detects 0 error for IN and OUT, from a unrecognized supplier. And the drive next to it detects 54 error for IN port and 7 for OUT.  

  • 0 in reply to Jianyu Wang
    TI__Genius 9465 points

    Hi Jianyu,

    May I know at what frequency the PRU Core Clock and IEP Clock are running at?

    We’ll check on the same configuration from our side and see the behaviour. 

    Regards,
    Aaron

  • 0
    Intellectual 270 points

    Hi Aaron

    The PRU Core Clock is 200Mhz

  • 0 in reply to Maor Shalom
    TI__Genius 9465 points

    Thank you Maor. I’ll check on how we can test this in our side and understand the behaviour. 

    Regards,
    Aaron

  • 0
    TI__Genius 9465 points

    Hi,

    Mu Logan said:
    Is there some ECAT register can reflect if PDI arrives physically?

    Sorry I missed this query earlier. You can map PDI ISR output to external SOC pin (via one of the 4 PRU-ICSS digio outputs):

    1. Program 0x0E0A Vendor Specific Register to choose between one of the 4 pins. For example, if you want to map the PDI ISR output to map to PRG1_IEP0_EDIO_DATA_IN_OUT31, then write 0x80 in the register. 0x40, 0x20 or 0x10 if you want to map to PRG1_IEP0_EDIO_DATA_IN_OUT30, PRG1_IEP0_EDIO_DATA_IN_OUT29 and PRG1_IEP0_EDIO_DATA_IN_OUT28 respectively.
    2. Map the corresponding EDIO pin to an available external GPIO pin in Syscfg:

    Couple of additional queries:

    1. How often is this behavior observed in the complete communication cycle? 
    2. Which EtherCAT MainDevice are you using for testing this?

    I'm checking on this through the physical pin and software side. Will get back to you if I'm able to see similar behavior.

    Regards,
    Aaron

  • 0 in reply to Jianyu Wang
    TI__Mastermind 48171 points
    Jianyu Wang said:
    In the network, there are 170+ nodes. 9 drives are connected to one port of a spliter, the first is XMC4800 which detected no frame loss, the rest are AM2432s. The first AM2432 detected 25 frame loss, second is 27, ..., the last is 5.

    Are there any frame captures available with tools which can track CRC errors?

    Jianyu Wang said:
    The first AM2432 detected 25 frame loss, second is 27, ..., the last is 5.

    Can you also share how these errors map to 0x300:0x303