• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 32 subscribers
  • Views 484 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.

MCU-PLUS-SDK-AM243X: Custom PHY - Unexpected state transition from

Alexander Göhrig
Prodigy 115 points
Part Number: MCU-PLUS-SDK-AM243X


Hi TI experts,

we are using a custom PHY driver in our firmware (using SDK 8.4.0.17 with lwip) and we were experiencing an unexpected behaviour with an Ethernet port that had no link to another Ethernet port.

We need to configure the link/act LEDs after the first reset to get these indicators to work properly. But in the case of an unconnected Ethernet port we observed a short flickering after ~ 8 seconds.

After we enabled the logging of the PHY states we found out there seems to be an auto-negotiation timeout which causes a reset followed by a new configuration of that PHY-port.

[17222]  DebugP: EnetPhy_phyTimeout: PHY 3: timeout has occurred
[17222]  DebugP: EnetPhy_setNextState: PHY 3: NWAY_WAIT -> FOUND (0 ticks)
[17322]  DebugP: EnetPhy_setNextState: PHY 3: FOUND -> RESET_WAIT (10 ticks)
[17422]  DebugP: EnetPhy_setNextState: PHY 3: RESET_WAIT -> ENABLE (0 ticks)
[17522]  DebugP: EnetPhy_enableState: PHY 3: enable
[17524]  DebugP: EnetPhy_enableState: PHY 3: req caps: FD100 HD100 FD10 HD10 
[17524]  DebugP: EnetPhy_enableState: PHY 3: PHY caps: FD100 HD100 FD10 HD10 
[17524]  DebugP: EnetPhy_enableState: PHY 3: MAC caps: FD1000 FD100 HD100 FD10 HD10 
[17524]  DebugP: EnetPhy_enableState: PHY 3: refined caps: FD100 HD100 FD10 HD10 
[17524]  DebugP: EnetPhy_enableState: PHY 3: PHY is NWAY-capable
[17524]  DebugP: EnetPhy_enableState: PHY 3: setup NWAY
[17524]  DebugP: EnetPhy_setupNway: PHY 3: NWAY advertising: FD100 HD100 FD10 HD10 
[17524]  DebugP: EnetPhy_setupNway: PHY 3: config is needed
[17525]  DebugP: EnetPhy_setupNway: PHY 3: restart autonegotiation
[17525]  DebugP: EnetPhy_setNextState: PHY 3: ENABLE -> NWAY_START (50 ticks)
[17622]  DebugP: EnetPhy_setNextState: PHY 3: NWAY_START -> NWAY_WAIT (80 ticks)
[25722]  DebugP: EnetPhy_phyTimeout: PHY 3: timeout has occurred
[25722]  DebugP: EnetPhy_setNextState: PHY 3: NWAY_WAIT -> FOUND (0 ticks)
[25822]  DebugP: EnetPhy_setNextState: PHY 3: FOUND -> RESET_WAIT (10 ticks)
[25922]  DebugP: EnetPhy_setNextState: PHY 3: RESET_WAIT -> ENABLE (0 ticks)
[26022]  DebugP: EnetPhy_enableState: PHY 3: enable
[26024]  DebugP: EnetPhy_enableState: PHY 3: req caps: FD100 HD100 FD10 HD10 
[26024]  DebugP: EnetPhy_enableState: PHY 3: PHY caps: FD100 HD100 FD10 HD10

In the doumentation to that SDK (AM243x MCU+ SDK: Ethernet PHY Integration Guide) I can not find information about the timeout and that state transition.

Increasing the nwayWaitStateTicks could be some kind of workaround, but what should I configure to disable the auto-negotiaition timeout completely?

ptPhyCfg->timeoutCfg.nwayWaitStateTicks = 0xFFFFFFFF;

Best regards

Alex

  • 0
    TI__Mastermind 48640 points

    Hi Alex,

    We have started looking into this issue. Let me come back by thursday

  • 0 in reply to Nilabh Anand
    TI__Mastermind 48640 points

    Can you please check the following:

    In file examples/networking/lwip/enet_lwip_cpsw/test_enet.c

    In function EnetApp_initLinkArgs() check for below line

    phyCfg->phyAddr and tell me what is the value of phyCfg->phyAddr.

  • 0 in reply to Nilabh Anand
    Prodigy 115 points

    Hi Nilab,

    the value is 3 or 7 depending on which port (ENET_MAC_PORT_1 or ENET_MAC_PORT_2) the EnetApp_initLinkArgs() is called.

    Just to clarify: we are using the lwip in our custom firmware with a custom PHY (TI DP83826) on our own hardware. We are not testing with an example on EVM.

    Best regards

  • 0 in reply to Alexander Göhrig
    TI__Mastermind 48640 points

    Hi Alex,

    Just to clarify here, are you saying that the phy which you have not connected cable to is getting up and running after 8 seconds?

    Also do you wish to disable that phy or you want to use it? Are you enabling both the phy from the driver or just one?

    Also from the prints it seems "EnetPhy_phyTimeout" Phy 3 is not using custom phy driver. The prints seem to point to internal phy driver.

    Is the first port(connected one) working properly.

  • 0 in reply to Nilabh Anand
    Prodigy 115 points

    Hi Nilabh,

    both ports are controlled by our custom PHY driver implemenation. PHY 7 is connected and running, PHY 3 is unconnected with link/act LED flickering every 8 seconds.

    The unconnected Port 3 is not running but is getting a reset every 8 seconds, which is the consequence of the auto-negotiation timeout. This leads to a link/act LED flicker in our case, because the LED are on after reset and the LEDs are configured properly after the config() call of our custom PHY driver.

    I was wondering why there is a reset after the Auto-Negotiation Timeout, I could not find such a state transittion in the PHY driver integration documentation. I would like to completely disable the auto-negotation timeout.

    the print-outs in my log come from the TI EnetPhy layer where our custom PHY driver is referenced by hPhy->hDrv pointer

  • 0 in reply to Alexander Göhrig
    TI__Mastermind 48640 points

    Thanks Alex for clarifying my question.

    From the initial observation:

    The following state in phy statemachine  ENETPHY_FSM_STATE_RESET_WAIT.

    It calls  EnetPhy_resetWaitState where in else case it calls EnetPhy_phyTimeout.

    Depending on phy is strapped ort not it call 

    ENETPHY_FSM_STATE_LINK_WAIT(strapped)
    or
    ENETPHY_FSM_STATE_FOUND
    Can you please tell me if phy is in strapped mode or not.
  • 0 in reply to Nilabh Anand
    Prodigy 115 points

    The phy is not in strapped mode, because i observed that otherwise the config() function of our phy driver would not be called

  • 0 in reply to Alexander Göhrig
    TI__Mastermind 48640 points

    Hi Alex,

    If phy is not in strapped mode then, the time out happens is from, the link_wait

    For removing the timeout 

    In the below function implementation

    static void EnetPhy_linkWaitState(EnetPhy_Handle hPhy), you can remove the line:

    state->timeout--;
    so that you never go to a timeout.
     
  • 0 in reply to Nilabh Anand
    Prodigy 115 points

    Hi Nilabh,

    I suppose removing the line you suggested from EnetPhy_linkWaitState() as you suggested would not solve my issue, because I am observing a state change from NWAY_WAIT to FOUND and not from LINK_WAIT to FOUND in my logs.

    Of course there are similar lines in the EnetPhy_nwayWaitState() function with I could remove but that was not my initial intention.

    I would have prefered a solution without modifiing and recompiling the SDK code (like setting the timeout value to 0 initially with disables the timeout handling) which was the main reason why I opened this e2e ticket.

    At all I was wondering why there is such a state transition from NWAY_WAIT to FOUND despite this is not documented.

    Best regards

    Alex

  • +1 in reply to Alexander Göhrig
    TI__Intellectual 1791 points

    Hi Alex,

    Alexander Göhrig said:
    I would have prefered a solution without modifiing and recompiling the SDK code (like setting the timeout value to 0 initially with disables the timeout handling) which was the main reason why I opened this e2e ticket.

    Unfortunately, we don't have the support to disable timeout for auto-negotiation in enetphy statemachine. So, we will add this support, which means, you may have to recompile the SDK if you like to take patch on your current SDK (before new SDK release).

    Alexander Göhrig said:

    At all I was wondering why there is such a state transition from NWAY_WAIT to FOUND despite this is not documented.

    In the documentation  AM243x MCU+ SDK: Ethernet PHY Integration Guide , It did not mention the error case when auto-negotiation does not complete or does not start in PHY. In the driver implementation, in these cases, driver marks are timeout and move to "STATE_FOUND", where the driver re-starts the process from beginning (PHY reset). 
    Hence the below state transition is possible as per the implementation-
      NWAY_START -> FOUND, NWAY_WAIT -> FOUND, LINK_WAIT -> FOUND.
    These transition is missed in the documentation of state transition. We will fix this in the SDK.