• State TI Thinks Resolved
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 95 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM2431: MCU+ SDK - DP83849I PHY support and custom PHY implementation

Michael V
Intellectual 586 points

Part Number: AM2431
Other Parts Discussed in Thread: DP83849I,

Hi,

I have questions regarding the use of the AM2431 with the DP83849I PHY, and I would appreciate your guidance on the recommended implementation approach.

While reviewing the AM243x MCU+ SDK documentation, I found that DP83849I is not included in the list of supported PHY devices. (Link)

I also found the Custom PHY guide describing the process for adding support for unsupported PHY devices.(Link)

I would appreciate clarification on the following :

  1. How can the DP83849I be used with AM2431 and the AM243x MCU+ SDK? 
  2. Does the process described in the Custom PHY guide assume that a PHY driver already exists, or is the customer expected to implement the PHY-specific driver functionality themselves?
  3. I could not find a DP83849I PHY driver for AM243x. Does TI provide a DP83849I PHY driver? If so, where can it be obtained?
    1. If no driver is available, what is the recommended approach for integrating DP83849I?
  4. Are there any references demonstrating DP83849I integration with AM2431 or other AM243x devices?
  5. Do you have any additional recommendations/pointers? 

Any guidance would be appreciated.

Best regards,

Michael

  • 0
    TI__Genius 9900 points

    Hi Michael,

    1. It can be used by adding the corresponding custom driver for the PHY into the build system
    2. Yes, the process assumes that there is an existing PHY driver available with corresponding format expected by MCU+ SDK
    3. I would have to check with our PHY team on the corresponding driver support.
    4. Currently, there are no references of using DP83849I with AM243x or AM64x
    5. You could start with going through the register map, and update any of the existing PHY drivers which have similar HW design. You can update the read and write sequences, and make a driver compatible to use with your PHY device

    Thanks and regards,
    Teja,

  • 0 in reply to Teja Rowthu
    Intellectual 586 points

    Hi Teja,

    Thank you for your response.

    In that case, as per .3, could you please check with the PHY team about the driver support? 
    If possible, I would like access to the driver to try utilizing in custom PHY implementation as outlined in the SDK documentation.

    If no driver is available, I would also appreciate a recommendation on the best alternative to the DP83849I. 

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Genius 9900 points

    Hi Michael,

    I will check with our team for the inputs. Since the team is based in US timeszones, please expect some delay in their response and in turn, the follow up response on this E2E.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Intellectual 586 points

    Hi Teja,

    Thank you for your response.

    Has there been any progress made on your end?

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Genius 9900 points

    Hi Michael,

    We do not have an available RTOS driver code for DP83849I. But the PHY configuration is closest to DP83822, with the register maps matching between DP83822 and DP83849I for Auto negotiation, Speed, MAC configs, and interrupt configs. This will have minor effort to bring up from existing driver.

    But the fiber and port-switching configs are new addition to the DP83849I PHY, so bringing this up will be the major effort comparatively. Do you need port switching for your end application? Is your PHY going to be fiber?

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Intellectual 586 points

    Hi Teja,

    Thank you for the follow-up.

    I do not believe the end application will require port switching or fiber operation, although I will need to confirm any future plans.
      
    In the meantime, we have been able to achieve the simple functionality using a dummy PHY driver.
    Based on your previous comments, I understand that modifications may be required depending on the specific PHY features that need to be supported.
    Since the PHY is already operational, I would appreciate clarification on when a custom DP83849I driver becomes necessary.
    Specifically, if the application never calls ETHPHY_command(), can the dummy driver continue to be used in place of a custom DP83849I driver, or are there scenarios where a custom DP83849I driver would still be required?
      

    I look forward to your response.

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Genius 9900 points

    Hi Michael,

    It would be preferable to have PHY specific driver always, since it enables the full feature set requirement for your application. If your application doesn't need fiber, then you need not include that in your version of PHY driver. 

    But if your application is working with the generic PHY driver implementation, and it fulfils your requirements, then you can continue using it. I am referring to your dummy PHY driver when I am using the term "generic PHY driver" in the following.

    But I would highly urge you to check few things before finalizing your driver version. 

    1. Please check you are able to use both auto-negotiation as well as fixed link configuration
    2. Check if you are able to issue reset commands to PHY via generic PHY driver
    3. Please check if you are able to change the mode of operation, if you are planning to switch between the MII and RMII modes (CPSW and ICSSG use RMII and MII respectively)
    4. Please check if the platform is able to handle link down and link up normally in runtime. Disconnect the ethernet cable after it gets link up, and check if the application is alive. The reconnect the PHY and check if the link up is handled correctly, and that the communication resumes.

    Since the current driver is working normally, to get link up, I am expecting the MDIO read and write functionality is working well.

    Based on these, you can decide if you would like to use generic PHY driver or PHY specific ethernet driver. 

    Best regards,
    Teja.