TMDSCNCD28388D: Converting example enet_lwip_udp to use RMII with same PHY but on custom board

Hi, 

Are you able to read and write to the PHY registers ?  PHY also has to be configured in RMII mode.  

Pls refer the example ethernet_ex2_phy_loopback provided within C2000Ware located at <C200Ware>driverlib\f2838x\examples\cm\ethernet\CCS.  This reads the PHY registers and configures it in MII mode.   Similarly , you will have to configure the PHY to be in RMII mode. 

Also make sure that RMII interface signals are correctly configured

If you are configuring the ENET_RMII_CLK as External Clock, then the PHY/external device should provide the clock.

Best Regards

Siddharth

Siddharth,  as you point out, "ethernet_ex2_phy_loopback" example reads and writes to a PHY register. However, that is merely for setting loopback mode for that test, and seems to have nothing to do with configuring that PHY for RMII mode.  In my application, I don't want packets to loop back.  I want the PHY to transmit outgoing packets. Is there something about the PHY registers that must be prepared specifically for RMII?  From the example you are pointing too, very little seems to concern RMII (vs. MII) configuration: one line in main() which sets initInterfaceConfig.phyMode.  I had already changed such a line in my own code to assign the RMII value to that field: 

initInterfaceConfig.phyMode = ETHERNET_SS_PHY_INTF_SEL_RMII;

as detailed above in my original post under number 1.  I also did this:

initInterfaceConfig.clockSel = ETHERNET_SS_CLK_SRC_EXTERNAL; 

Yes, we plan on using the clock from the DP83826ERHB PHY. 

In my c28x code, as detailed above, I configured the pins according to our board schematics, for RMII (or so I intended).  Please review what I changed on the lines of code as described above under number 2. 

I understand your point that any PHY connected to the microcontroller will need registers setup for any non-default configuration required.

I have this document from the TI site for TI PHY  DP83826ERHB: "https://www.ti.com/lit/ds/symlink/dp83826e.pdf?ts=1692824765093&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDP83826".

I will study it carefully for anything related to register setup for RMII mode.  It is a close part number to the PHY referenced in the example you cited, but I note that it is not identical. Again, I saw nothing in the example you cited related to REGISTER writes to a PHY for RMII configuration, so I was confused by your reply in that respect.

[EDIT 8/24 p.m.] - 

Later today 8/24 after reviewing the PHY documentation linked above, I see that our board is using "pin boostraps" to configure some PHY features without the need for writing to PHY registers. For example, PHY pin 1 is shorted to GND, which means our PHY is in "BASIC mode". In BASIC mode, Pin 21 is for issuing an interrupt only, and does not function as a PWRDN pin at all. So I commented-out code from the examples which tries to bring the PHY out of "power-down" by asserting that pin.  Also, our board uses STRAP4 on pin 18 to bring up the PHY for RMII mode. So YES, the PHY is already configured for RMII mode.  I have set the pin mux (as seen in my notes above) for the RMII signals.  Still, I have no ping after the code runs.  

After reviewing what I have done and described, what am I missing (if anything) in the software configuration for using RMII mode instead of MII?  Is there anything lacking or incorrect in what I've done in software that would prevent pings from working or my callback from being invoked?

As detailed in my Aug 24 post, the board uses "pin bootstraps" to configure the DP83826ERHB PHY in hardware in its BASIC mode and for RMII ethernet. 

As mentioned earlier, my code sets phMode for RMII and for the external PHY clock:

initInterfaceConfig.phyMode = ETHERNET_SS_PHY_INTF_SEL_RMII;

initInterfaceConfig.clockSel = ETHERNET_SS_CLK_SRC_EXTERNAL;

I exercised the example you cited (ethernet_ex2_phy_loopback) with the C28x project setup for the correct RMII pin assignments, etc, and the CM project assigning the phyMode and clockSel.  The statement which reads the PHY register in the example returns 0xFFFF, which does not seem right.

I can't see what's missing (if anything). Do you have any ideas about what else I can do in software that I should be doing?  Or do you have any ideas on further troubleshooting this?  

Hi, 

Is there a way to confirm that the PHY is configured correctly ?   which PHY register are you trying to read? .

Pls read the RCSR register to determine the PHY RMII configuration.  

Following is the code snippet for reference.

phyRegContent = Ethernet_readPHYRegister(EMAC_BASE,0x1); //Base,Address

//
//Address 0 of PHY corresponds to Basic Mode Control Register(BMCR)
//Read the register to know the state
//
phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0);

//
//Bit 12 of BMCR configures the Auto-Negotiation - turn it off
//
phyRegContent &= 0xEFFF;
//Ethernet_writePHYRegister(EMAC_BASE,0,phyRegContent);

//
//Bit 8 of BMCR configures the duplex capability - set to full duplex
//
phyRegContent |= 0x100;
Ethernet_writePHYRegister(EMAC_BASE,0,phyRegContent);

//
//Read back the BMCR register to confirm that it is configured properly
//
phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0);

// configure PHY in RMII Mode in RMII and Status Register (RCSR)
phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0x17);

phyRegContent |= 0x20;
Ethernet_writePHYRegister(EMAC_BASE,0x17,phyRegContent);

//
//Read back the RCSR register to confirm that it is configured properly
//
phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0x17);

Also, observed that you are selecting external clock for RMII clocking.  In this case, the ENET_RMII_CLK pin of the device should be provided with the required 50-MHz clock.

Best Regards

Siddharth

Siddharth Deshpande said:

Is there a way to confirm that the PHY is configured correctly ?   which PHY register are you trying to read? .

As mentioned in my prior post, I used the example you cited (ethernet_ex2_phy_loopback).  That example reads the BMCR register.  A read of that register returned 0xFFFF.  The portion of the example main() which does this is as follows:

    //
    //Low Frequency
    //value of 5 for selecting the slowest possible MDIO Clock
    //Clause 22 mode
    //
    Ethernet_configureMDIO(EMAC_BASE,0,5,0);

    //
    //The DP83822 External PHY in Control Card
    //takes a PHY address of 1 by default
    //Configure the MDIO module to use PHY address of 0x1
    //
    Ethernet_configurePHYAddress(EMAC_BASE,1);

    //
    //Address 0 of PHY corresponds to Basic Mode Control Register(BMCR)
    //Read the register to know the state
    //
    phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0);

I see you have posted some additional instructions to use MDIO to query the PHY configuration and I will paste those statements into the example and execute it. 

Also, I am following-up with my board design engineer to verify the clock signal is being sent by the PHY to the microcontroller.

I will follow up immediately afterward here with the results.

I added the statements and executed. Here are the results. The hex number in the left margin is the value of phyRegContent after each execution of each statement which might change it:

0x0
    phyRegContent = Ethernet_readPHYRegister(EMAC_BASE,0x1); //Base,Address
0xFFFF

    //
    //Address 0 of PHY corresponds to Basic Mode Control Register(BMCR)
    //Read the register to know the state
    //
    phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0);
0xFFFF

    //
    //Bit 12 of BMCR configures the Auto-Negotiation - turn it off
    //
    phyRegContent &= 0xEFFF;
0xEFFF
    //Ethernet_writePHYRegister(EMAC_BASE,0,phyRegContent);
    //
    //Bit 8 of BMCR configures the duplex capability - set to full duplex
    //
    phyRegContent |= 0x100;
0xEFFF
    Ethernet_writePHYRegister(EMAC_BASE,0,phyRegContent);
    //
    //Read back the BMCR register to confirm that it is configured properly
    //
    phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0);
0xFFFF
    // configure PHY in RMII Mode in RMII and Status Register (RCSR)
    phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0x17);
0xFFFF
    phyRegContent |= 0x20;
0xFFFF
    Ethernet_writePHYRegister(EMAC_BASE,0x17,phyRegContent);
    //
    //Read back the RCSR register to confirm that it is configured properly
    //
    phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0x17);
0xFFFF

James, 

The EMAC configuration looks correct to me.  If the PHY and the RMII clock is configured correctly , then it should work fine. 

Let us know your observations regarding the Clock.

Best Regards

Siddharth

Thank you for evaluating the EMAC configuration. I'll let you know what I find about the PHY clock output to the microcontroller. I'm asking my colleague if we can probe the signal.  But you were guiding me to use MDIO to check the PHY configuration. Does it seem wrong to you that my PHY register read operations are always returning 0xFFFF?  What can cause that?  That doesn't seem right to me.

James, 

The register always returning 0xFFFF doesn;t seem right.   Will request the PHY team to look in to it and see if something is missing.

Best Regards

Siddharth

I look forward to hearing from you or the PHY team about the MDIO so we can look at PHY registers.  In answer to  your question about the PHY clock output, we did verify the 50 MHz clock is being output from the PHY. So far, you've reviewed my EMAC configuration (looks good), and we have verified the PHY is putting out the 50 MHz clock.  Reads over the MDIO serial interface are returning 0xFF for the BMCR and RCSR registers, which we agree is probably incorrect.  That is where things stand at the moment.  Do you have any other ideas?

Hi James,

Can you please let me know if the register access is not working from the start or you just lost the access recently?

Can you also share the schematic of the design?

--
Regards,
Gokul.

Hi Gokul.  No, I have not yet seen PHY register access work on our board (not working from the start).  We have a Proprietary Information Agreement with TI, so yes, we can share design schematics in a non-public forum.  On 9/14 I requested a meeting (for using screen share) via Brad Caldwell (TI Processor Field Applications) so we can share design details with your team.  Mr. Caldwell replied, "I just pinged our apps manager again to bring this to his attention. I asked if we can get a call setup with an expert, waiting to see what he comes up with. I'll get back to you."  I have not heard back from Brad Caldwell about setting up the call yet.  On 9/21 I emailed him, explaining we are waiting for news about setting up a call with screen-share.

Hi James,

To understand why the MDIO access is not available, we need to check

1. Circuit or schematic of the MDC, MDIO in your design
2. Health of the PHY (whether the PHY powered-up, power-up timing etc.)

I can share my email address over a personal message to you. You can share the schematic over email.

On the health of the device, can you please let me know the following?

1. Is there a link observable on the link partner when it is connected?
2. During the hardware bring-up, are there any signs that the hardware is working fine that are observable by you or your team?

Can you please do the following captures?

1. Capture-1:
   Signal on MDI lines (i.e., TD_P and TD_M)
   Disconnect the link partner and terminate TD_P and TD_M with a 100 ohm differential termination.
   Probe the TD_P and TD_M differential signal using a differential probe and capture the waveform.
   
   
2. Capture-2:
   Signal on MDC, MDIO when register access is done
   Read register 0x1 and capture the waveform of MDC and MDIO in a single snap which is zoomed in to see the edge transitions of MDC, MDIO.

We will look into power-up timing and other captures if the above two captures yield us no results.

--
Regards,
Gokul.