DP83826I: 100M mode, Never get RX_D[x] signal and RX_ER always comes just like RX_DV

Hi Xuan,

I would like to make sure I understanding the question correctly:

• So far everything works fine with 10Mbps for link up and package sent and received.
• Are you able to see a link up with 100Mbps?
• Could you check the register for 0x0001, 0x0004, and 0x0005

--

Regards,

Hillman Lin

• So far everything works fine with 10Mbps for link up and package sent and received. Yes, totally work. lwip example is working perfectly. Ping works, simple Web server works. 
• Are you able to see a link up with 100Mbps?  May I ask How to define the link up in these situation.  I saw the 100M / 3 level signal built up on oscilloscope , but can not pass RJ45 cable loopback test. No mention, it can not get Ping by using Lwip example.   
• Could you check the register for 0x0001, 0x0004, and 0x0005.  will do it soon  and post the result. 

thanks very much! 

Hi Xuan,

Register 0x0001 will provide the information on link up. I will wait for your response.

--
Regards,

Hillman Lin

Hello Hillman, 

I got reading from my CCS codes. This is the register's value. Looks Valid link established. Looking forward your help. Thanks 

0x0000 = 0010000100000000b

0x0001 = 0111100001001101b

0x0004 = 0000000111100001b

0x0005 = 0000000000000000b

Hi Xuan,

Did you have a link partner when you are reading the register? I did not see any advertisement on the link partner side?

--

Regards,

Hillman Lin

Hillman, 

I am doing external loopback test. 

I was doing with a router, but nothing happen so that I step back to do RJ45 cable loopback. 

I could connect to a router and to get 0x0005 , if you think that could help to debug. again, the current most strange thing is that the PHY never put data on RX[3:0] when I do external loopback.  But the physical single on the RD_p/n is already so good. 

Hi Xuan,

For further debug, Could you provide me the step on how you do the external loopback?

--

Regards,

Hillman Lin

of course, overall I use same code for 10M and 100M based on c2000 MII_PHY_loopback example but get rid of MII loopback setup. By using same codes, 10M always get passed but once enable 100M never get any RX[3:0] signal back to MAC of DSP, of course no RX package at all. 

1) load RAM of CPU1 of the f28388D

2) load RAM of CM core

3) run CPU1 for GPIO initialization, and run CM core for the registers writing. 

4) tried keep the loopback cable plugin in and plug the cable after DSP run. 

5) monitor the CAT5 cable on the short point (1 to 3, 2  to 6) by oscilloscope. I could see the 100M link characteristic pattern every time. 

6) I kept sending the TX package, but never get any RX package in CCS debugger. 

7) test with oscilloscope physically. No signal on RX_D[3:0] pins of the PHY, and RX_ER of PHY always acts like a RX_DV meaning PHY is throwing out a error. 

Hi Xuan,

Since it getting link up from 100mpbs, the problem most likely lies on the MAC interface. I have couple question to ask you for a further debug:

• What MAC interface are you using?
• How did you configure to 100Mbps? are you configure it based on the auto negotiation? or are you forcing it to 100mbps mode?
• Could you also provide the information for 0x0468

--

Regards,

Hillman Lin

1) we use MII

2) we tried both, once force to 100 or auto to 100, no received package when we do external loopback. 

3) 0468, our board shows 0087, while DP83826EVM board shows 02A2. 

Please see total comparation between EVM and our board. others are all same. 

Hillman, 

Please also look into my electricity test of the DP83826, please let me know if you have any suggestion. 

e2e.ti.com/.../4125222

Hi Xuan,

Are you able to perform an MII loopback in your board? MII loopback can be enable through bit[14] in register 0000 and bit[12] in register 0016. I would like to know rather it is the internal board issue or the MAC interface issue. Please let me know rather you are able to receive an data when you run the MII loopback? Please refer to section 9.3.14 in the datasheet for further detail.

--

Regards,

Hillman Lin

Hi,

I am Hai xuan's teammate. We can confirm that we have no issues with performing a MII loopback with the DP83826EVM when its breakout board was connected to the GPIO pins of a TMS320F28388D controlCARD (Rev. A). In fact, we can even run the MII loopback example CCS project, ethernet_ex2_phy_loopback, from C2000Ware almost as is (we only slightly increased the waiting time after packet transmission). In that small firmware program, we only set bit 14 of the BMCR (register 0x0000) and, contrary to the instructions given in the datasheet and on this forum, DID NOT set bit 12 in register 0x0016.

We've also managed to perform MII loopbacks with the PHY on our board, but it requires that there be no MCU GPIO pin assigned to serve as the Ethernet RX_ERR pin. If we assign a pin to serve as the RX_ERR then we get receive errors and we do not get the returning packet data. If no pin is assigned then we do not get receive errors and we are able to get the returning packet data.

Obviously, we should have a pin assigned to get the RX_ERR signal during normal operation. But regardless of whether or not the RX_ERR pin is assigned, it is still not possible for our board to establish a 100 Mbps link speed during normal operation.

Hi Howard,

Since you are not able to perform MII loopback with RX_ER connected. I believe your problem might be the timing issue on the MAC interface. For the further debug, could you scope the timing requirement on the MAC interface and make sure it satisfy the following requirement?

--

Regards,

Hillman Lin

We would like to reiterate that our TMS320F28388D controlCARD, a TMDSCNCD28388D (it is a Revision A controlCARD instead of the newer Revision B controlCARDs if it is of any importance), attached to a TMDSHSECDOCK baseboard, has managed to utilize the DP83826E on the DP83826EVM to send and receive Ethernet packets. While the MDIO and MDC are still controlled by the MSP430F5529 on the DP83826EVM, the CRS, COL, RXCLK, RXDV, RXER, RXD[0:3], TXCLK, TXEN, TXD[0:3] pins are all under the control of the TMS320F28388D microcontroller on our TMDSCNCD28388D controlCARD.

To perform a MII loopback, we used the USB2MDIO desktop program to set bit 14 of the Basic Mode Control Register (PHY register address 0x0). Then we successfully ran the C2000Ware example firmware program, ethernet_ex2_phy_loopback, with almost no modifications (the only differences between the original example code and our modified code are the lines that pertained to PHY register management are commented out as the MSP430F5529 microcontroller was responsible for setting the PHY registers and made the wait time after outputting a packet just a little bit longer).

//#############################################################################
//
// FILE:   ethernet_ex2_phy_loopback.c
//
// TITLE:  Ethernet Basic Transmit and Receive External (PHY) Loopback Example
//
//! \addtogroup driver_example_cm_list
//! <h1> Ethernet Basic Transmit and Receive PHY Loopback </h1>
//!
//! This example demonstrates the steps to be followed in using the
//! Ethernet of the Communication Manager Subsystem to initialize
//! the Ethernet module and Configure the module in External Loop back mode
//! the packet is looped back at external PHY.
//! Prepares a packet to be sent, Sends the packet and reads the staticstics
//! to check if the packet is received by the module
//! Before running this Communication Manager code the C28x cpu1 code has to be run
//! to configure the clocks to Communication manager
//! and required IO pads for Ethernet module
//!
//! \b External \b Connections \n
//!  This example programs the Ethernet module in External Loop back mode (at PHY)
//! and hence needs external connection to the PHY on the MII interface and
//! also the MDIO Pins connected to the PHY. This example assumes DP83822 PHY
//! for the PHY configurations if a different PHY is used the sequences might change
//! Refer to the C28x CPU1 code of ethernet_config_c28x project
//! for which GPIOs are used for connecting to the PHY
//!
//! \b Watch \b Variables \n
//!  - phyRegContent variable can be checked to know if PHY register
//! read,write is working correctly
//!   - stats to know if the packet is received correctly after loopback
//! at PHY side
//
//#############################################################################
// $TI Release: F2838x Support Library v3.04.00.00 $
// $Release Date: Fri Feb 12 19:08:49 IST 2021 $
// $Copyright:
// Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/
//
// Redistribution and use in source and binary forms, with or without 
// modification, are permitted provided that the following conditions 
// are met:
// 
//   Redistributions of source code must retain the above copyright 
//   notice, this list of conditions and the following disclaimer.
// 
//   Redistributions in binary form must reproduce the above copyright
//   notice, this list of conditions and the following disclaimer in the 
//   documentation and/or other materials provided with the   
//   distribution.
// 
//   Neither the name of Texas Instruments Incorporated nor the names of
//   its contributors may be used to endorse or promote products derived
//   from this software without specific prior written permission.
// 
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
// $
//#############################################################################

//
// Included Files
//
#include "driverlib_cm.h"
#include "cm.h"

//
// Defines
//
#define PACKET_LENGTH 132

#define ETHERNET_NO_OF_RX_PACKETS   1U
//
//Change this define for changing Packet buffer length
//
#define ETHERNET_MAX_PACKET_LENGTH 1538U


//
// Globals
//
uint8_t Ethernet_rxBuffer[ETHERNET_NO_OF_RX_PACKETS *
                          ETHERNET_MAX_PACKET_LENGTH];

uint8_t pData[PACKET_LENGTH];


//
// Main
//
void main(void)
{

   Ethernet_InitInterfaceConfig initInterfaceConfig;
   Ethernet_InitConfig *pInitCfg;
   Ethernet_Pkt_Desc pktDesc;
   uint32_t i;
   Ethernet_Statistics stats;
   Ethernet_Handle emac_handle;
   uint16_t phyRegContent=0;

    //
    // Initialize device clock and peripherals
    //
    CM_init();

   //
   //Form the unicast Packet in Memory
   //
   for(i=0;i<PACKET_LENGTH/4;i++)
   {
        //
        //First 6 bytes of the packet are the MAC Destination Address
        //Bytes, the Destination and CRC shall be inserted by the hardware
        //
       if(i == 0)
           *((uint32_t *)pData + i) = 0x01020304;
       else if(i == 1)
           *((uint32_t *)pData + i)  = 0xFFFF0506;
       else
           HWREG((uint32_t *)pData +i) = 0xFFFFFFFF;
   }

   //
   //Select the MII interface of the module
   //
   initInterfaceConfig.ssbase = EMAC_SS_BASE;
   initInterfaceConfig.enet_base = EMAC_BASE;
   initInterfaceConfig.phyMode = ETHERNET_SS_PHY_INTF_SEL_MII;
    //
    //Assign SoC specific functions for Enabling,Disabling interrupts
    //and for enabling the Peripheral at system level
    //
    initInterfaceConfig.ptrPlatformInterruptDisable = &Platform_disableInterrupt;
    initInterfaceConfig.ptrPlatformInterruptEnable = &Platform_enableInterrupt;
    initInterfaceConfig.ptrPlatformPeripheralEnable = &Platform_enablePeripheral;
    initInterfaceConfig.ptrPlatformPeripheralReset = &Platform_resetPeripheral;
    //
    //Assign the peripheral number at the SoC
    //
    initInterfaceConfig.peripheralNum = SYSCTL_PERIPH_CLK_ENET;
    //
    //Assign the default SoC specific interrupt numbers of Ethernet interrupts
    //
    initInterfaceConfig.interruptNum[0] = INT_EMAC;
    initInterfaceConfig.interruptNum[1] = INT_EMAC_TX0;
    initInterfaceConfig.interruptNum[2] = INT_EMAC_TX1;
    initInterfaceConfig.interruptNum[3] = INT_EMAC_RX0;
    initInterfaceConfig.interruptNum[4] = INT_EMAC_RX1;

    pInitCfg = Ethernet_initInterface(initInterfaceConfig);

    //
    // Get an initial configuration of known good parameters
    //
    Ethernet_getInitConfig(pInitCfg);
    //
    //Assign the callbacks for Getting packet buffer when needed
    //Releasing the TxPacketBuffer on Transmit interrupt callbacks
    //Receive packet callback on Receive packet completion interrupt
    //
    pInitCfg->pfcbGetPacket = &Ethernet_getPacketBuffer;
    pInitCfg->pfcbFreePacket = &Ethernet_releaseTxPacketBuffer;
    pInitCfg->pfcbRxPacket = &Ethernet_receivePacketCallback;
    //
    //Assign the Buffer to be used by the Low level driver for receiving
    //Packets. This should be accessible by the Ethernet DMA
    //
    pInitCfg->rxBuffer = Ethernet_rxBuffer;

    //
    //The Application handle is not used by this application
    //Hence using a dummy value of 1
    //
    Ethernet_getHandle((Ethernet_Handle) 1,pInitCfg , &emac_handle);

    //
    //Do global Interrupt Enable
    //
    (void)Interrupt_enableInProcessor();
    //
    //Assign default ISRs
    //
    Interrupt_registerHandler(INT_EMAC_TX0, Ethernet_transmitISR);
    Interrupt_registerHandler(INT_EMAC_RX0, Ethernet_receiveISR);
    //
    //Enable the default interrupt handlers
    //
    Interrupt_enable(INT_EMAC_TX0);
    Interrupt_enable(INT_EMAC_RX0);

    /** PHY register management is not applicable when interfacing with the DP83826EVM **/
//    //
//    //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);
//
//    //
//    //Bit 14 of BMCR configures the MII Loopback
//    //
//    phyRegContent |= 0x4000;
//
//    Ethernet_writePHYRegister(EMAC_BASE,0,phyRegContent);
//
//    //
//    //Read back the BMCR register to confirm that the MII Loopback
//    //is configured properly
//    //
//    phyRegContent= Ethernet_readPHYRegister(EMAC_BASE,0);

    //
    //Prepare a Packet Descriptor structure to send a packet
    //This contains a single buffer single packet
    //The Source address shall be inserted by the MAC
    //Packet CRC is auto computed by the module and appended in the packet
    //
    pktDesc.bufferLength = PACKET_LENGTH;
    pktDesc.dataOffset = 0;
    pktDesc.dataBuffer = pData;
    pktDesc.nextPacketDesc = 0;
    pktDesc.flags = ETHERNET_PKT_FLAG_SOP |ETHERNET_PKT_FLAG_EOP|ETHERNET_PKT_FLAG_SA_INS;
    pktDesc.pktChannel = ETHERNET_DMA_CHANNEL_NUM_0;
    pktDesc.pktLength = PACKET_LENGTH;
    pktDesc.validLength = PACKET_LENGTH;
    pktDesc.numPktFrags = 1;

    //
    //Send the packet prepared
    //
    Ethernet_sendPacket(emac_handle,&pktDesc);


    //
    //Delay for the MAC to send the packet on the wire and receive it
    //
    SysCtl_delay(3000*3); /** We need to wait just little bit longer than 3000 cycles **/

    //
    //Read the statistics of the Module
    //
    Ethernet_getStatistics(emac_handle, &stats);

    //
    //Check if a packet has been received
    //
    if(!stats.rxUnicastPacketsGood)
        __asm("   bkpt #0");

}

Moreover, this setup with the controlCARD and the DP83826EVM can even successfully run the more complex enet_lwip example project (that firmware program turns the controlCARD into a simple web server serving a simple interactive HTML page) with no modifications to the firmware code whatsoever for both 10 Mbps and 100 Mbps link speeds.

Therefore, it cannot possibly be a MAC timing issue because if there were MAC timing issues with the TMS320F28388D microcontroller, the TMS320F28388D microcontroller on our controlCARD should have failed in the same manner as the TMS320F28388D microcontroller on our proprietary board; but it did not and instead it successfully ran the aforementioned test programs that we gave it. Furthermore, there is no way for the firmware to change the MAC receive and transmit timings; such timing behavior is built into the silicon of the microcontroller.

Lastly, here are the MAC RX and TX timing tables and diagrams straight from the TMS320F28388D datasheet for your reference:

Addendum 1:

The 10Mbps and 100Mbps MII timings of both the DP83826 and the DP83822 (the Ethernet PHY found on the TMDSCNCD28388D controlCARD) are completely identical according to their respect datasheets.

I would put more information about timing. 

Howard explained f28388D should not have any timing issue to DP83826. Here my points is all RX, TX traces in our PCB are matched. I did not see any possibility to have the timing issue because traces. 25Mhz is such a small piece of cake. Even we do not do any trace match in a 2 inch area should not have problem. 

Would you Please help to confirm

1) if the RD and TD output of DP83826 should have same offset voltage level. 

2) is the DP83826 really be very sensitive with 'Pedestal Voltage on VDDA3V3, VDDIO before Power Ramp'. 

Hi Howard and Xuan,

Thank you for your patient. I do think I am with you on MII timing requirement might not be the root cost of the issue. If you have a timing requirement issue, you can still receive some signal from RX_D[x] when you send signal from MDI side. I do think the problem might be in the power up constraint. May I ask some question and provide some procedure for further debug:

• Did you write any extra register every time you power up the PHY?
• You are able to get a link up on 100mpbs right? If so can you try the following:
• Have you try to hard reset when there is data transfer on the MDI side to see rather you get any signal coming from RX_D[x]?
• Can you also write 001F to 8000 to see rather you see some signal coming from RX_D[x] when you are transferring data on MDI side.
• Could you provide a snapshot on the supply voltage to see the supply voltage ramp up?
• Could you also put a snapshot on the oscillator in the oscilloscope?
  
  

"In fact, we can even run the MII loopback example CCS project, ethernet_ex2_phy_loopback, from C2000Ware almost as is (we only slightly increased the waiting time after packet transmission)."

Are you using a board that is separate from your original board design for the MII loopback?

--

Regards,

Hillman Lin

Hillman Lin said:

Are you using a board that is separate from your original board design for the MII loopback?

That example project works without error on our TMDSCNCD28388D controlCARD (a Texas Instruments product) for both the PHY that is on the controlCARD (i.e. a DP83822 Ethernet PHY) and the PHY on the DP83826EVM (i.e. the DP83826 Ethernet PHY). Our proprietary board also uses a TMS320F2888D microcontroller and a DP83826 PHY but it cannot perform the same example project without errors.

Hi Howard,

Thank you for the clarification. I will wait for your further update.

--

Regards,

Hillman Lin

For our proprietary board, bits 10 and 9 in the PHYSTS Register (register address 0x10) are not set when we attempt to run the web server example firmware project (i.e. enet_lwip) with a 100 Mbps link. For the controlCARD connected to the DP83826EVM via wires between the controlCARD base board and DP83826EVM breakout board, when we run the same example firmware project with a 100 Mbps link those same bits in the PHYSTS Register are indeed set.

Bit 9 pertains to a "100Base-TX Descrambler Lock indication from PMD" and Bit 10 pertains to a "100Base-TX unconditional Signal Detect indication from PMD".

EDIT1: I've found some documentation regarding Ethernet compliance tests.

How to Configure DP838xx for Ethernet Compliance

How to Pass IEEE Ethernet Compliance Tests

Other than the Compliance Test Register, I want to know what other PHY registers I need to configure in order to prepare the PHY for such tests.

Hi Howard,

We will test out the compliance for DP83826EVM in the lab today and provide you the response later this week.

--

Regards,

Hillman Lin

Thanks for the response.

When doing the compliance tests, could you also note the DC offsets of the RD and TD analog signals?

Hi Howard,

I double check in the lab today for the 100Base-TX on Dp83826 PHY. I did not see any DC offsets of the RD and TD analog signal. For the 100Base-TX standard MDI test please use the following script:

• Reg 0x001F = 0x8000 //reset PHY 
• Reg 0x0000 = 0x2100 //programs DUT to 100Base-TX Mode 
• Reg 0x0010 = 0x5008 //programs DUT to Forced MDI Mode

--

Regards,

Hillman Lin

Hillman Lin said:

I did not see any DC offsets of the RD and TD analog signal.

Hi Hillman,

Sorry for the late response, but when you say that there were no DC offsets, is that for the RD and TD signals relative to each other? We measured the RD and TD signals of the DP83826EVM using our own equipment and indeed they do not have any noticeable offsets between each other. But what about the absolute offsets of the RD and TD signals to ground?

Hi Howard,

May I ask couple questions:

• why DC offset is being measure for the compliance test?
• Since MDI is an AC couple system, DC offset shouldn't matter for the RD and TD signals to ground.

--

Regards,

Hillman Lin