• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 84 subscribers
  • Views 387 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28388D: Getting RMII to work

Nils Larsen
Prodigy 70 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: DP83640,

Hello!
We have a TMS320F28388D ControlCARD (with onboard PHY using MII interface) and a custom PCB with TMS320F28388D and a TI DP83640 PHY wired with RMII interface. I can't get the latter to work, for example with the ethernet_ex4_ptp_basic_master. Can you help me making the necessary changes for RMII and debugging why it is not working?

What I did:

  • First, I got the example 'ethernet_ex4_ptp_basic_master' running on the ControlCARD. I only had to define the macro "ETHERNET" in the cm_common_config_c28x project. I can see the PTP messages in Wireshark each second, as expected.
  • Then I modified the pins for our custom hardware for RMII:

        //
        // Configure the GPIOs for ETHERNET.
        //

        //
        // MDIO Signals
        //
        GPIO_setPinConfig(GPIO_105_ENET_MDIO_CLK);        // PHY: MDC
        GPIO_setPinConfig(GPIO_106_ENET_MDIO_DATA);       // PHY: MDIO

        //
        // Use this only for RMII Mode
        GPIO_setPinConfig(GPIO_73_ENET_RMII_CLK);         //PHY: X1

        //
        //RMII Signals
        //
        GPIO_setPinConfig(GPIO_75_ENET_MII_TX_DATA0);     //PHY: TXD_0
        GPIO_setPinConfig(GPIO_122_ENET_MII_TX_DATA1);    //PHY: TXD_1

        GPIO_setPinConfig(GPIO_118_ENET_MII_TX_EN);       //PHY: TX_EN

        GPIO_setPinConfig(GPIO_114_ENET_MII_RX_DATA0);    //PHY: RXD_0
        GPIO_setPinConfig(GPIO_115_ENET_MII_RX_DATA1);    //PHY: RXD_1
        GPIO_setPinConfig(GPIO_113_ENET_MII_RX_ERR);      //PHY: RX_ERR
        GPIO_setPinConfig(GPIO_112_ENET_MII_RX_DV);       //PHY: CRS/CRS_DV

  • Additionally, I had to define USE_20MHZ_XTAL because that is what our custom board has.
  • Finally, I changed this line in ethernet_ex4_ptp_basic_master
    initInterfaceConfig.phyMode = ETHERNET_SS_PHY_INTF_SEL_RMII;
    and added
    initInterfaceConfig.clockSel = ETHERNET_SS_CLK_SRC_INTERNAL;

Via SMI I can verify that a 100Mbit full-duplex link is negotiated (VALID LINK flag goes high). I can also measure activity on TX_EN, TXD_0, TXD_1 (every second as expected by the example) and RMII_CLK/X0. But, alas, nothing can be seen in Wireshark.
Did I miss to something when migrating the code from MII to RMII?
Are the any registers of the EMAC that I can use to debug the problem?
We did check all the strapping pins of the PHY and verified the configuration via SMI (RMII mode, RMII Slave Clock Mode).

We would be grateful for any hints.
Best regards, Nils

  • 0
    TI__Mastermind 33415 points

    Nils,

    From the SW side , the changes done for RMII look to be correct.   

    1. Did you verify the RMII clock.? You have configured it to be internal . Ensure that the clock source and divider are set accordingly to provide a 50-MHz clock.

    2. Are you able to read/write to the PHY registers?  Pls check for the Link status in the PHY register BMSR.

    Best Regards

    Siddharth

  • 0 in reply to Siddharth Deshpande
    Prodigy 70 points

    Hello Siddharth, thank you for your suggestions! But yes, we have verified that the C2000 outputs 50MHz on GPIO_73. I did not change clock source and divider from the examples. I described all the clock-related changes I did (everything else is left as in the original example), those were the USE_20MHZ_XTAL and ETHERNET_SS_CLK_SRC_INTERNAL-stuff.

    Also, we can read PHY registers via SMI and get a VALID LINK in the link status of BMSR. I think this would be impossible, if the clock were not correct?

    Do you have further ideas?

    Best regards, Nils

  • 0 in reply to Nils Larsen
    TI__Mastermind 33415 points

    Nils,

    I don't have any other inputs at this point.  The changes that you have done for RMII seem to be fine. 

    Let me forward this query to the PHY team to see if they have any inputs or suggestions.

    Best Regards

    Siddharth

  • 0 in reply to Siddharth Deshpande
    TI__Mastermind 18801 points

    Hi Nils,

    I saw this late in the day and haven't had time to full review, please allow another day to go over. Will respond again tomorrow.

    Regards,

    Alvaro

  • 0 in reply to Alvaro (Al-vuh-roe) Reyes
    Prodigy 70 points

    Great, thanks. I'm grateful for you assistance.

  • 0 in reply to Nils Larsen
    TI__Mastermind 18801 points

    Hi Nils,

    Before diving too deep into anything, can we do a couple Health checks on the PHY?

    • Probe the CLKOUT pin
      • This is like seeing a heartbeat, expected output is a 25 MHz square wave.
    • Link
      • Are you getting link? You can see link by reading Register 0x1.

    Regards,

    Alvaro

  • 0 in reply to Alvaro (Al-vuh-roe) Reyes
    Prodigy 70 points

    Hello Alvaro,

    sure! Here is the output from CLKOUT.
    Yes, like I wrote in my first post, we can read the SMI registers and we are getting a valid link.

    Best regards,
    Nils

  • 0 in reply to Nils Larsen
    TI__Mastermind 18801 points

    Hi Nils,

    I want to point out that the DP83640 is an older part and support is limited. I say this because I do not have access to a board with the part and cannot verify some of the device's behavior.

    I might have overlooked something, are you configuring the PHY into RMII Slave? If so the PHY requires a 50 MHz input clock, which would lead me to expect a 50 MHz waveform from CLKOUT. Can you confirm that the input clock is 50 MHz?

    Regardless, you were able to measure a waveform from CLKOUT which means the PHY is up. When a PHY Links up but has no data through-put, it is usually indicative of a connection issue in the MAC interface. The PHY and MAC may not be communicating properly. We can test this by placing our PHY in MII Loopback mode. You'll have to program the MAC on the TMS320F28388D to begin transmitting data and see if it receives the data back. If data is received, then the MAC interface is okay and the issue is elsewhere. Please see Section 5.3.5 Internal Loopback in the DP83640 Data sheet for more information on Loopback Configuration (it requires Register Write Access). 

    Regards,

    Alvaro

  • 0 in reply to Alvaro (Al-vuh-roe) Reyes
    Prodigy 70 points

    Thank you for the hints.
    Yes, the PHY is configured as RMII Slave (we verified that it receives a 50MHz clock from the Delfino on its X1 pin).
    Following your hint, I enabled the PHY internal loopback, which led to a very interesting result: The Rx_Multicast_Packets_Good counter counts the sent and looped packets without loss. So the RMII communication cannot be (totally) broken.
    The PHY also has a Remote Loopback mode. When I enable it, the packets send from the connected Windows PC to the PHY show up doubled in Wireshark - they are all looped back by the PHY -, so I assume that also the Ethernet side of the PHY is working.
    We are totally puzzled why no packets pass between the RMII side and the Ethernet side of the PHY - in either direction. It looks like "isolation mode", but that mode is of course disabled.
    We'll make some measurements on the RMII signals tomorrow, comparing the waveforms (especially ENET_RX, RMII CLK, RX_DV) when in a) receiving packets from a working Ethernet device (which is not working) and b) receiving packets in loopback mode (which is working).
    We would be grateful for more hints. Best regards, Nils

  • 0 in reply to Nils Larsen
    TI__Mastermind 18801 points

    Thank you Nils,

    I'll await the waveforms and consult with my team for further debug strategies.

    Regards,

    Alvaro

  • 0 in reply to Alvaro (Al-vuh-roe) Reyes
    Prodigy 70 points

    The measurements led us to the solution: The clock was correct for 100Mbit (50MHz), bit the RX0 and RX1 signals were much too slow, because the MAC was operating in 10Mbit mode. The default setting for link speed in the MAC_Configuration register is 10Mbit and the driverlib-examples do not touch that bit (FES) anywhere (warm suggestion for an improvement!). I guess it is not necessary to change the bit when using the Controlcard (MII mode and external clock, unlike our RMII mode and internal clock), which could be why "noone" has noticed.

    So if anyone else wants to use RMII mode and internal clock:

    • Start out with the provided examples from TI
    • Change the pin configuration for RMII pins in the CPU1 code
    • Add this configuration to the CM code:
      initInterfaceConfig.phyMode = ETHERNET_SS_PHY_INTF_SEL_RMII;
      initInterfaceConfig.clockSel = ETHERNET_SS_CLK_SRC_INTERNAL;
    • And finally (this was our missing bit FES):
      #define ETHERNET_MAC_CONFIGURATION_100MBIT 0x4000U
      Ethernet_setMACConfiguration(EMAC_BASE, ETHERNET_MAC_CONFIGURATION_100MBIT);
      (of course, this must match the PHY settings)