AM3357: Lost Link Counter is getting 0x0101 at boot up

Hi
Which EtherCAT Slave package is the customer using here?

Regards
Dhaval

Hi Dhaval,

Here is the feedback on the software version from customer

• ESC version : 0x03b3
• Base software at the development of software : AM335x sysbios SDK 1.0.0.8

The issue was found in their end customer and they need to make a report on how to handle the issue ASAP.

Please understand our situation and we need your help to solve the issue.

Your understanding would be highly appreciated.

Michiaki Tanii

Hi
Can you ask customer to make following change in "protocols/ethercat_slave/include/tiesc_pruss_intc_mapping.h" file and test?

Line 147

- {MII_LINK0_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_PULSE},\

+ {MII_LINK0_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\

Line 152

- {MII_LINK1_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_PULSE},\

+ {MII_LINK1_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\

Regards
Dhaval

Hi Dhaval,

Customer has already changed tiesc_pruss_intc_mapping.h as attached.

Please see the attached which is based on AM335x sysbios SDK 1.0.0.8.

* Line # does not match for line 147 and 152.

And also they found the same issue with the below ESC version.

0x03b3

0x03e3

0x04ef

Could you kindly advise your assumption how long it takes to find out root cause ?

Customer needs to report to end user when we can close the issue.

Your understanding would be highly appreciated.

Michiaki Tanii

0777.tiesc_pruss_intc_mapping.h

Hi Dhaval,

Customer needs your help ASAP because the issue was found at end user and they need to report on the issue how to solve it.

Please understand our situation and your prompt response is highly appreciated.

Michiaki Tanii

Hi Dhaval,

Could you give us your situation or any update ?

Thank you and best regards,

Michiaki Tanii

Hell Tanii-san

This is still under investigation.  Dhaval is the subject matter expert on this, but he will be out starting today till Nov 2nd. So unfortunately we will need more time to complete our investigation and post some guidance. I will not be able to allocate this to someone else while Dhaval is out of office. 

We will try to provide another update on Nov 4th. 

Regards

Mukul 

Tanii-san

Can you ask the customer to try configuring LED_LINK polarity to Active High? We are suspecting that this issue is seen if the polarity is active low for the LINK pin from the PHY.

Regards
Dhaval

Tanii-san,

Let me summarize our analysis and status so far, following-up on Dhaval's question with some more details.. Can you help to answer the following questions?

1. We understand that the link_loss counter is starting off with 1 vs expected to be 0. Is this correct? Please note that we are trying to reproduce the issue on TI EVM.
2. LED_LINK polarity – can you please confirm with customer if this is active_high or active_low for their HW?
3. We have worked with customer on EtherCAT using Sitara MPU devices for several years now. Why is customer reporting this issue now? – is this a new team/new HW/HW change?
4. What is the end result for them – broken certification? Broken use case?
5. Can we request to follow-up discussions in E2E directly? Will be good if customer engineers can engage directly in E2E.

You may note that we are still working on this issue; we can provide updates in E2E as soon as we have any findings.

best regards,

Girish

1. We understand that the link_loss counter is starting off with 1 vs expected to be 0. Is this correct? Please note that we are trying to reproduce the issue on TI EVM.
   <Answer>
   Yes. For more details, Lost Link Counter is different from expected value when power up. 
   Lost Link Counter@00310   
   - Expected value : 0x0000 
   - Actual value      : 0x0101
   
   
2. LED_LINK polarity – can you please confirm with customer if this is active_high or active_low for their HW?
   <Answer>
   Customer's setting is active_low.
   <Question>
   What kind of role does LED_LINK signal take care of ?
   When change from active_low to active_high, would you let us know more detail mechanism why it can be a workaround?
   
   
3. We have worked with customer on EtherCAT using Sitara MPU devices for several years now. Why is customer reporting this issue now? – is this a new team/new HW/HW change?
   <Answer>
   Customer just got this behavior from their end customer these day. 
   Don't know if it occured from the beginning of mass production or recently.
   Customer previously used TI Ether PHY then now they are using Microchip Ether PHY.
   However, this unexpected behavior can be seen on both TI and Microchip.
   TI Ether PHY                : TLK100
   Microchip  Ether PHY   : KSZ8081MLX
   
   
4. What is the end result for them – broken certification? Broken use case?
   <Answer>
   So fa no information. Will check with customer.
   
   
5. Can we request to follow-up discussions in E2E directly? Will be good if customer engineers can engage directly in E2E.
   <Answer>
   Sure. Let's use E2E.
   
   
   Additional information 
   Version of SDK : sysbios SDK 1.0.0.8
   Version of ESC Link lost counter issue occured : 0x03b3 0x03e3 0x04ef 
   2.4. PRU ICSS EtherCAT Slave Controller Register List — PRU-ICSS Industrial Software for Sitara Processors (ti.com)

Hi

Tetsuro Kasai said:

What kind of role does LED_LINK signal take care of ?

LED_LINK signal is responsible for providing the link status indication to PRU-ICSS, and responsible for link lost counter increment.

LED_LINK signal from the PHY provides the MII link up/down information to MDIO of PRU-ICSS. If MLINK mode is enabled in the MDIO (which is the case for), any change in LED_LINK is used to trigger an interrupt which goes to PRU-ICSS. PRU-ICSS uses this interrupt to increment this link lost counter.

From our debug so far, our suspicion is that this LED_LINK's polarity being active low might be linked to this issue. Therefore we want the customer to try changing the polarity to active_high and observe the behavior. In the meanwhile, we are trying to confirm our suspicion and get more details. 

Regards
Dhaval

Let me summarise the situation as below.

1. Behavior 
   Lost Link Counter always becomes 0x0101 just after power up. Lost Link Counter becomes always 0x0101. Other value never be seen.
   

   Condition	HW	Ether CAT Master	TwinCAT3
   		MPU (EtherCAT Slave)	TI : AM3357BZCZD30
   		Ether PHY   (EtherCAT Slave)	TI            : TLK110 (before) Microchip  : KSZ8081MLX (now)
   	SW	Version of SDK :	sysbios SDK 1.0.0.8
   		Version of ESC Link lost counter issue occurred	0x03b3 0x03e3 0x04ef
   Result	Issue	Lost Link Counter	Lost Link Counter is different from expected value when power up. Lost Link Counter@00310   - Expected value : 0x0000 - Actual value      : 0x0101

2. Question to your answer
   Thank you for your reply.
   It's a bit difficult to understand relationship between LED_LINK's polarity and Lost Link Counter.
   1) Would you let us know how LED_LINK's polarity impacts on Lost Link Counter in this block diagram?
   2) When polarity is changed from High to Low by Software, how PRU-ICSS hardware behavior changes ? If it is shown by timing chart, it would be very clear to understand.
   
   

Hi

Tetsuro Kasai said:

1) Would you let us know how LED_LINK's polarity impacts on Lost Link Counter in this block diagram?

As you see above, this register indicates an link interrupt by monitoring the MDIOLINK register.

When we are using the LED_LINK based link detection, we update the LINKSEL bit to 1 in MDIOUSERPHYSEL0 and MDIOUSERPHYSEL1 registers as shown above.

The default value of LINKSEL bit is 0. So if there is no link in any ports, the MDIOLINK register value will be 0x0.

AM335x ICE board has two Ethernet PHYs at address 0x1 and 0x3 with polarity of MLINK/LED_LINK as "Active Low". In case of no link in any ports, when we configure this MDIOUSERPHYSEL0/MDIOUSERPHYSEL1 register, the MDIOLINK register goes from 0x0 to 0xA (Bit 1 and Bit 3 set), because no link means bit should be set to 1 for those PHYs. Now MDIOLINKINTRAW sees this as an link state change and sets the interrupt. EtherCAT firmware sees this as an actual link change and increments the link lost counter (0x310). 

Above explanation holds only for "Active Low" polarity. In case of "Active High" polarity, no such interrupt will be seen.

Therefore, can you please try changing the polarity of LED_LINK as "Active High" and check?

Regards
Dhaval

1.  Who changes LINKSEL bit ?  
     
   you said
   "If MLINK mode is enabled in the MDIO (which is the case for), any change in LED_LINK is used to trigger an interrupt which goes to PRU-ICSS"
    " MLINK mode is enabled in the MDIO " = "LINKSEL bit = 1" ?
   
   Why is this LINKSEL bit change ? 
   
   LINKSEL bit = 0 determine link status using MDIO state machine (default)  -> 1 :  determine link status using from MLINK pin 
   
   
2.  MLINK/LED_LINK as "Active Low"   
    3-1
    you answered  "the MDIOLINK register goes from 0x0 to 0xA (Bit 1 and Bit 3 set), because no link means bit should be set to 1 for those PHYs."
    What does "Active Low mean"? Is my understading below correct ?  
     - When there is link with Active Low, MDIOLINK register = 0 
     - When there is no link with Active Low,  MDIOLINK register = 1 
   
   3-2
    - Who sets MLINL/LED_LINK as "Active/Low"? Is it build configuration ? or set by firmware ? 
   
   3-3
    - What is the exact setting  for "Active/High" ? You answered previously as below. Should customer just change the code as beloew?
   

   "protocols/ethercat_slave/include/tiesc_pruss_intc_mapping.h" file and test?
   
   Line 147

   - {MII_LINK0_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_PULSE},\

   + {MII_LINK0_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\

   Line 152

   - {MII_LINK1_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_PULSE},\

   + {MII_LINK1_EVENT, CHANNEL1, SYS_EVT_POLARITY_HIGH, SYS_EVT_TYPE_EDGE},\

   
   Customer tried 2 ways as below
   1) LINKSEL bit = 0 determine link status using MDIO state machine (default)  -> 1 :  determine link status using fromMLINK pin
   Result 
    Lost link coutner start increment from 0x0000. When using TwinCAT3, it worked, however customer's master software failed the communication. 
   2) Set link0pol adn ink1pol to HIGH directly
   

   Before：

           pmdio_params->link0pol = TIESC_LINK_POL_ACTIVE_LOW;

           pmdio_params->link1pol = TIESC_LINK_POL_ACTIVE_LOW;

   After：

           pmdio_params->link0pol = TIESC_LINK_POL_ACTIVE_HIGH;

           pmdio_params->link1pol = TIESC_LINK_POL_ACTIVE_HIGH;
   
   

   
   No improvement. Lost Link Counter starts from 0x0101. TwinCAT3 could not detect AM335. Communiction also failed.

I'm sorry, the customer's test result I wrote had some mistake. Let me correct it.

Customer tried 2 ways as below

1) Change "enhancedlink_enable" from "ENABLE" to "DISABLE"

Before：mdioParamsInit.enhancedlink_enable = TIESC_MDIO_RX_LINK_ENABLE;

After：mdioParamsInit.enhancedlink_enable = TIESC_MDIO_RX_LINK_DISABLE;

Lost link counter starts count from 0x0000. 

However, EtherCAT communication starts to fail on customer's equipment, although EtherCAT communication using TwinCAT3 was succeeded. TwinCAT3 may take care of something to cover some degradation.


2) Set link0pol adn ink1pol to HIGH directly

Before：

        pmdio_params->link0pol = TIESC_LINK_POL_ACTIVE_LOW;

        pmdio_params->link1pol = TIESC_LINK_POL_ACTIVE_LOW;

After：

        pmdio_params->link0pol = TIESC_LINK_POL_ACTIVE_HIGH;

        pmdio_params->link1pol = TIESC_LINK_POL_ACTIVE_HIGH;

No improvement. Lost Link Counter starts from 0x0101. TwinCAT3 could not detect AM335. Communiction also failed.

For LED_LINK signal and polarity, we would like to clarify the relationship between MLINK pin (PHY) and Lost Link Counter(AM335) more detail.

According to the previous answer, 

at MLINK mode (LINKSEL bit = 1),  LED_LINK is used to trigger an interrupt which goes to PRU-ICSS.

at this condition, when MLINK polarity = "Active_low",

what is the trigger to increment Lost Link Counter ? If there are any mistake below, would you correct it?
   for example when MLINK pin = H to L 
   -> LED_LINK signal via MDIO (PHY)
   -> PRU-ICSS(AM335)
   -> Interrupt(AM335)
   -> Lost Link Counter increment (AM335) 

what is the state or trigger NOT to incremant  Lost Link Counter ? If there are any mistake below, would you correct it?
  for example when MLINK pin = L to H , stay H  or stay L 
  -> No LED_LINK signal via MDIO (PHY) 

Thanks.