AM6442: Configure PHY Register (Auto-negotiation) from Application

Adding on some additional context and references for your convenience.

Board: AM64x EVM

MCU+SDK: v10.00.00.20

PSDK (Linux): v10.00.07.04

Regarding BCMR Register on the DP83869 PHY:

• By default, auto-negotiation bit is set (on), at BMCR register is set to 0x1140, but they want to turn it off so 0x140 should be written to BMCR register

Regarding the R5F App:

• They have a CLI program to write/read PHY register value like below
• They have tried two patterns (using ENET_IOCTL and EnetPhy driver API)

• ENET_IOCTL used to read reg value:
  • 
• ENET_IOCTL used to write reg value:
  • 
• EnetPhy driver API used to read reg value:
  • 
• EnetPhy driver API used to write reg value:
  • 

They checked getting and setting reg values w/ and w/out a network connection.

In the situation that they DON'T connect to a network, here are the results:

• 
  • Initially, BMCR value is read as 0x1140
  • They try to change BMCR value to 0x140 using ENET_IOCTL
  • After changing, it remains 0x140 for around 2~3 secs, but returns to original value (please check AUTONEG_EN bit)
• 
  • Initially BMCR value is read as 0x1140
  • They try to change BMCR value to 0x130 using EnetPHY API
  • After changing, it remains 0x140 for around 2~3 seconds, but returns to original value (in this case sometimes they can read out the set value 0x140 more than once using CLI)

In the situation that they DO connect to a network, here are the results: (ethernet router connected)

• 
  • Initially BMCR value is read as 0x1140
  • Try to set BMCR value to 0x140 using ENET_IOCTL
  • Link down, link up occurs
  • Returns to original 0x1140 value
• 
  • Produces similar results when using EnetPHY API

Hi Nitika,

I see that you have been assigned to the thread and have shared the TI drive link with you via email.

Best regards,

Mari Tsunoda

Hi Mari,

Thank you for the information, I will check it and get back to you.

Regards,

Nitika

Hi Mari,

I have gone through the sample code, and the PHY driver functionality. The current routine is triggering a link reset, and thus taking the PHY through the link up process again. But since the PHY handle is not updated to the new link configuration, the PHY is still ending up in the same configuration as the beginning. 

The current PHY driver doesn't support updating the link configuration during runtime directly is not available, as the MAC port link config should also be in sync with PHY link. So, if there is no problem with link re-negotiation time, you can follow the following routine:

Updating Link Config:

1. Trigger Link-down event from application: This should include setting the macport state to DISABLED
2. Use "ENET_PER_IOCTL_CLOSE_PORT_LINK"  IOCTL to close PHY
3. Update the linkCfg, initially configured in "EnetApp_enablePorts" to the required configuration.
   This should have both the PHY link config and MACPORT link config. Please make sure to keep them same.
4. Set the MACPORT state to FORWARDING using the IOCTL "CPSW_ALE_IOCTL_SET_PORT_STATE"
5. Now, use "ENET_PER_IOCTL_OPEN_PORT_LINK" to initialize the PHY driver with updated configuration.

This is the preferred method to do it, without changing the drivers. If the link re-establishment time is critical, then you can consider using External Phy Management using "enetExtPhy.c". But this is not a state machine implementation, and is carried out in a loop. You can add additional API to update the details of updated params in the PHY handle config. By calling this API before triggering the PHY register write in the sample code, you can achieve same functionality. But these changes will not be maintained going forward in MCU plus SDK

Thanks and regards,
Teja.