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: CRC error occurs when 100Mbps is selected for Ethernet

Part Number: TMS320F28388D
Other Parts Discussed in Thread: DP83822I, C2000WARE, TMDSCNCD28388D, TMDSHSECDOCK

I am developing an Ethernet using TMS320F28388D.
The PHY being spec'd is dp83822i.

(Configuration is described below)

I am using the C2000ware driver to make the initial Ethernet settings. When I set "10Mbps", both transmit and receive succeed, but when I set "100Mbps", there are many errors when receiving.

Looking at the Statistic, the cause of the errors seems to be "rxCRCErrorPackets". 10Mbps does not cause this problem.

The PHY BMCR is selected correctly, so I do not think there is a problem on the PHY side. auto-nego is checked with OFF, but the same behavior is observed with ON.

The test environment consists of two boards with the above environment and a program in which only the MAC address has been changed.

TMS320F28388D <--(RMII)--> dp83822i <--(Full/100M)--> dp83822i <--(RMII)--> TMS320F28388D

Is there anything I have forgotten to set when using "100Mbps"?

    Ethernet_InitInterfaceConfig initInterfaceConfig;
    Ethernet_InitConfig *pInitCfg;

    initInterfaceConfig.ssbase = EMAC_SS_BASE;
    initInterfaceConfig.enet_base = EMAC_BASE;
    initInterfaceConfig.phyMode = ETHERNET_SS_PHY_INTF_SEL_RMII;
    initInterfaceConfig.clockSel = ETHERNET_SS_CLK_SRC_EXTERNAL; // PHY : RMII Master mode. PHY output 50Mhz clock. EMAC input.

    initInterfaceConfig.ptrPlatformInterruptDisable = &Platform_disableInterrupt;
    initInterfaceConfig.ptrPlatformInterruptEnable = &Platform_enableInterrupt;
    initInterfaceConfig.ptrPlatformPeripheralEnable = &Platform_enablePeripheral;
    initInterfaceConfig.ptrPlatformPeripheralReset = &Platform_resetPeripheral;

    initInterfaceConfig.peripheralNum = SYSCTL_PERIPH_CLK_ENET;
    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);

    Ethernet_getInitConfig(pInitCfg);
    
    pInitCfg->pktMTU      = 1536;
    pInitCfg->numChannels = 2;

    for ( i = 0U; i < pInitCfg->numChannels; i++ ) {
        pInitCfg->chInfo[ETHERNET_CH_DIR_TX][i].numBD = 1;
        pInitCfg->chInfo[ETHERNET_CH_DIR_TX][i].chNum = i;
        pInitCfg->chInfo[ETHERNET_CH_DIR_RX][i].numBD = 8;
        pInitCfg->chInfo[ETHERNET_CH_DIR_RX][i].dmaBufferSize = 384; // dmaBuffSize <<= 2 ; // RX Only
        pInitCfg->chInfo[ETHERNET_CH_DIR_RX][i].chNum = i;
    }

    pInitCfg->emacSSConfig.phyIntfSel = ETHERNET_SS_CTRLSTS_PHY_INTF_SEL_RMII;
    pInitCfg->emacSSConfig.clkSrcSel  = ETHERNET_SS_CTRLSTS_CLK_SRC_SEL_EXTERNAL;
    pInitCfg->emacSSConfig.LoopBackModeClkSel = ETHERNET_SS_CTRLSTS_LMCLKSEL_NORMAL;
    pInitCfg->emacSSConfig.flowControlEn = ETHERNET_SS_CTRLSTS_FLOW_CTRL_EN_DISABLED;

    pInitCfg->loopbackMode = ETHERNET_MAC_CONFIGURATION_LM_LOOPBACK_DISABLED;
    pInitCfg->maxPacketLengthRxBuffer = 1536;

    pInitCfg->dmaMode.TxRxArbitration  = ETHERNET_DMA_OPERATION_MODE_DA_ROUND_ROBIN; // DA    //
    pInitCfg->dmaMode.TransmitPriority = 0;                                          // TXPR  // Priority Rx
    pInitCfg->dmaMode.PriorityRatio    = ETHERNET_DMA_OPERATION_MODE_PR_TX4_RX1;     // PR    // Rx4:Tx1

    pInitCfg->linkMode  = ETHERNET_MAC_CONFIGURATION_DM_FULL_DUPLEX;

    pInitCfg->pfcbGetPacket  = &func_CB_pfcbGetPacket; // self
    pInitCfg->pfcbRxPacket   = &func_CB_pfcbRxPacket;  // self
    pInitCfg->pfcbFreePacket = &func_CB_pfcbFreePacket;// self

    /* Since the buffer for descriptors is managed and operated by the user,
       pInitCfg->rxBuffer is not necessary. */

    Ethernet_getHandle((Ethernet_Handle)1, pInitCfg, &etHandel);
    
    Ethernet_clearMACConfiguration( EMAC_BASE, 0x2 ); // TX Disable
    Ethernet_clearMACConfiguration( EMAC_BASE, 0x1 ); // RX Disable
    
    (void)Interrupt_enableInProcessor();
    Interrupt_registerHandler(INT_EMAC_TX0, Ethernet_transmitISR);
    Interrupt_registerHandler(INT_EMAC_TX1, Ethernet_transmitISR);
    Interrupt_registerHandler(INT_EMAC_RX0, Ethernet_receiveISR);
    Interrupt_registerHandler(INT_EMAC_RX1, Ethernet_receiveISR);
    Interrupt_enable(INT_EMAC_TX0);
    Interrupt_enable(INT_EMAC_TX1);
    Interrupt_enable(INT_EMAC_RX0);
    Interrupt_enable(INT_EMAC_RX1);

    /* MAC Address Set */
    uint32_t mac[2] = {0};
    device->emacMACaddrCfg.channelNum = 0; // instanseNUM  0 = ETHERNET_O_MAC_ADDRESS0, 1 = ETHERNET_O_MAC_ADDRESS1, 2... 0-7
    mac[0] = ((uint32_t)m_MAC.addr[4]  <<  8 | m_MAC.addr[5]);
    mac[1] = ((uint32_t)m_MAC.aaddr[0] << 24 | m_MAC.addr[1] << 16 |
                        m_MAC.aaddr[2] <<  8 | m_MAC.addr[3]);
    Ethernet_setMACAddr( EMAC_BASE,           // Base Address
                         0,                   // InstansNum 0-7
                         mac[0],              // MAC Address HIGH
                         mac[1],              // MAC Address LOW
                         ETHERNET_CHANNEL_0); // CHANNEL0 or CHANNEL1
    
    /* Change Speed, Duplex */
    uint16_t mdio_reg = PHY_MdioRegRead( 0x0010 );
    /* linkSpeed ( MAC_Configuration Register "FES" ) */
    if ( (mdio_reg & 0x2) != 0 ) Ethernet_clearMACConfiguration( EMAC_BASE, ((uint32_t)1 << 14) ); // EMAC 100Mbps
    else                         Ethernet_setMACConfiguration( EMAC_BASE, ((uint32_t)1 << 14) );   // EMAC 10Mbps
    /* linkMode ( MAC_Configuration Register "DM" ) */
    if ( (mdio_reg & 0x4) != 0 ) Ethernet_setMACConfiguration( EMAC_BASE, ((uint32_t)1 << 13) );   // EMAC Full Duplex
    else                         Ethernet_clearMACConfiguration( EMAC_BASE, ((uint32_t)1 << 13) ); // EMAC Half Duplex

    Ethernet_setMACConfiguration( EMAC_BASE, 0x2 ); // TX Enable
    Ethernet_setMACConfiguration( EMAC_BASE, 0x1 ); // RX Enable

  • Hi,

    Will take a look at you  code and get back in a couple of days.

    Best Regards

    Siddharth 

  • MDIO setting value.

    0x0000 : 00100001 00000000
    0x0001 : 01111000 01001101
    0x0004 : 00000001 11100001
    0x0005 : 00000000 00000000
    0x0009 : 00000000 00100000
    0x000A : 00000001 00000000
    0x000B : 00010000 00000000
    0x0010 : 01100110 00000101
    0x0012 : 00000000 00100000
    0x0013 : 00000000 00000000
    0x0016 : 00000001 00000000
    0x0017 : 00000000 01100101
    0x0019 : 10000100 00000001
    0x001A : 00000000 00000000

    The setting value of GPIO used for Ethernet.

    static void gpioInitSet( uint32_t pin, GPIO_Direction pinIO, GPIO_CoreSelect core, GPIO_QualificationMode qual, uint32_t pinType, uint32_t pinConfig )
    {
        GPIO_setDirectionMode( pin, pinIO );
        GPIO_setMasterCore( pin, core );
        GPIO_setQualificationPeriod( pin, qual );
        GPIO_setPadConfig( pin, pinType );
        GPIO_setPinConfig( pinConfig );
    }

    gpioInitSet( 38, GPIO_DIR_MODE_IN, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_38_ENET_MII_RX_DV );
    gpioInitSet( 39, GPIO_DIR_MODE_IN, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_39_ENET_MII_RX_ERR );
    gpioInitSet( 42, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_42_ENET_MDIO_CLK );
    gpioInitSet( 43, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_43_ENET_MDIO_DATA );
    gpioInitSet( 53, GPIO_DIR_MODE_IN, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_53_ENET_MII_RX_DATA1 );
    gpioInitSet( 56, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_56_ENET_MII_TX_EN );
    gpioInitSet( 59, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_59_ENET_MII_TX_DATA0 );
    gpioInitSet( 66, GPIO_DIR_MODE_IN, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_66_ENET_MII_RX_DATA0 );
    gpioInitSet( 73, GPIO_DIR_MODE_IN, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_73_ENET_RMII_CLK );

  • Hi, 

    I am out of office during the entire next week. Will get back to this once I am back in office.

    Best Regards

    Siddharth

  • Hi, 

    Are you using the CRC Checksum offload engine for computing the CRC? 

    Can you share your entire CCS project to take a look?

    Best Regards

    Siddharth

  • Hi.

    I have not changed the EMAC settings except for the basic description.
    The contents of the COE are as follows

    - MAC_Configuration Register (0x400C0000)
    IPC = 0 (default) 
    - MAC_HW_Feature0 Register (0x400C011C)
    RXCOESEL = 1 (default)
    TXCOESEL = 1 (default)

    The SRC code is attached with the necessary parts extracted.
    The GPIOs used are from my environment and need to be changed.

    PHY setting is used by dp83822i.
    Each switch is located in the header.

    best regard.

    20221014_TIQuery_Ethernet.zip

  • Hi,

    Will take a look and get back to you.

    Best Regards

    Siddharth

  • Hi Gouki Ono,

    Are you testing with a custom board? To rule out a hardware related issue, have you tested with F2838x ControlCard boards (TMDSCNCD28388D) already? This could be something to check in parallel while Siddharth reviews your software.

    Also, are you using 100BASE-TX (standard RJ45 / CATx cable) or 100BASE-FX (fiber)?

    Best,

    Kevin

  • Hi Kevin.

    I am testing with a custom board. use 100BASE-TX. "Cat5e"

    I have a TMDSCNCD28388D (nothing on the Rev) and have actually checked it by lighting LEDs, etc.
    I have not checked it with a test board because I had problems running Ethernet.

    - TMDSCNCD28388D "MCU063B"?
    - TMDSHSECDOCK    "MCU047A"?

    I have this environment and when I use the project I passed in Reply, (almost no changes except GPIO)
    It seems that both transmit and receive are failing due to the state that DMA is not free.

    After investigating the contents, it seems that the MDIO of the PHY cannot be obtained and is not configured.
    The PHY on the custom board is DP83822i, so there seems to be no difference from the test board.

    To begin with, the J4 port does not appear to be working.
    The LEDs don't work either.
    Do I need to configure anything?
    Two boards are connected and power is supplied from J17 on the DOCK side.

    I was going to set it up as I was running it, so I don't know if the registers are set up correctly.
    The basics have not changed much from the project above.

    - I changed the MII setting to "RMII->MII".
    initInterfaceConfig.phyMode = ETHERNET_SS_PHY_INTF_SEL_MII;

    - I have configured the Ethernet GPIOs as follows, but
    Could you please check if this is correct as I didn't find any clear documentation?

    ======================================================
    // GPIO - Ethernet(MII)
    GPIO_writePin(108,1); // PHY out of Power Down
    GPIO_writePin(119,1); // PHY out of Reset
    
    gpioInitSet( 44, GPIO_DIR_MODE_IN,   GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_44_ENET_MII_TX_CLK );    // TX_CLK
    gpioInitSet( 75, GPIO_DIR_MODE_OUT,  GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_75_ENET_MII_TX_DATA0 );  // TX_D0
    gpioInitSet( 105, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_105_ENET_MDIO_CLK );     // MDC
    gpioInitSet( 106, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_106_ENET_MDIO_DATA );    // MDIO
    gpioInitSet( 108, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_PULLUP, GPIO_108_ENET_MII_INTR );  // INT/PWDN
    gpioInitSet( 109, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_109_ENET_MII_CRS );      // CRS/CRS_DV/LED_CFG
    gpioInitSet( 110, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_110_ENET_MII_COL );      // COL/PHYAD0/MLED
    gpioInitSet( 111, GPIO_DIR_MODE_IN,  GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_111_ENET_MII_RX_CLK );   // RX_CLK
    gpioInitSet( 112, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_112_ENET_MII_RX_DV );    // RX_DV/MII_MODE
    gpioInitSet( 113, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_113_ENET_MII_RX_ERR );   // RX_ER/AMDIX_EN
    gpioInitSet( 114, GPIO_DIR_MODE_IN,  GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_114_ENET_MII_RX_DATA0 ); // RX_D0/PHYAD1
    gpioInitSet( 115, GPIO_DIR_MODE_IN,  GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_115_ENET_MII_RX_DATA1 ); // RX_D1/PHYAD2
    gpioInitSet( 116, GPIO_DIR_MODE_IN,  GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_116_ENET_MII_RX_DATA2 ); // RX_D2/PHYAD3
    gpioInitSet( 117, GPIO_DIR_MODE_IN,  GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_117_ENET_MII_RX_DATA3 ); // RX_D3/PHYAD4/CLKOUT
    gpioInitSet( 118, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_118_ENET_MII_TX_EN );    // TX_EN
    gpioInitSet( 119, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_PULLUP, GPIO_119_ENET_MII_TX_ERR );// RESET
    gpioInitSet( 122, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_122_ENET_MII_TX_DATA1 ); // TX_D1
    gpioInitSet( 123, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_123_ENET_MII_TX_DATA2 ); // TX_D2
    gpioInitSet( 124, GPIO_DIR_MODE_OUT, GPIO_CORE_CM, GPIO_QUAL_SYNC, GPIO_PIN_TYPE_STD, GPIO_124_ENET_MII_TX_DATA3 ); // TX_D3
    ======================================================

    best regard.

  • Hi Gouki Ono,

    We have a number of EtherNET software examples in the C2000WARE project. Have you already run those on the TMDSCNCD28388D hardware before? They're located at the install directory location below.

    • C:\ti\c2000\C2000Ware_4_01_00_00\driverlib\f2838x\examples\cm\ethernet

    These examples are intended to be run with the TMDSCNCD28388D hardware you have. The 'ethernet_c28x_config' project will need to run on the C28 core first, which initializes the GPIOs and device clocks. You can review that project for proper GPIO initialization.

    We also have some Third Party protocol / stack support examples located below:

    • C:\ti\c2000\C2000Ware_4_01_00_00\libraries\communications\Ethernet\third_party

    Best,

    Kevin

  • Hi Kevin.

    I am aware of the sample.
    Using the sample, a custom board has been created that works at "10Mbps-FULL".
    I've attached the working project in the reply above. please confirm.
    As you can see inside, the contents of the Ethernet settings are almost the same.

    I haven't tested it on my test board. The reason why you can't
    If you change GPIO and MII in this project and use the rest as is for TMDSCNCD28388D,
    The data from the MDIO is '0xFFFF' and it doesn't seem to be read correctly.

    This issue has just been resolved. The problem with the test board was again in the GPIO.
    The problem was that Pins 109 and 119 were assigned functions incorrectly.
    I was able to fix this and confirm that MDIO is received, so I plan to check it using a test board.

    best regard.

  • Hi Kevin.

    I confirmed the operation on the test board.
    As a result, the test board is running at "100-Full". (100Full MII loopback works fine)

    Regarding the difference between the test board and the custom board, the communication of "PHY<-->EMAC" is "MII or RMII".

    Since MII is working reliably on the test board, we believe that the current Ethernet configuration is correct.

    Test Results
    ==============================================================
    Testboard TX --(MII)---> dp83822i --(100M/Full)--> dp83822i --(RMII)--> Customboard RX
    "10000 cnt, 10000 OK"

    Customboard TX --(RMII)--> dp83822i --(100M/Full)--> dp83822i --(MII)---> Testboard RX
    "10000 cnt, 2276 OK"

    Testboard TX <--(MII)---> dp83822i (MII Loopback)
    "10000 cnt, 10000 OK"

    Customboard TX <--(RMII)--> dp83822i (MII Loopback)
    "10000 cnt, 1950 OK"
    ==============================================================

    From the above results.
    MII on the Testboard appears to be working correctly.
    Also, when the custom board is set to receive and the testboard is set to transmit, it is receiving correctly.

    Conversely, when the custom board is set to transmit, there are many errors.

    Given that "Receive at RMII" is successful.
    I believe that there is a mistake in "sending during RMII".
    Have you ever checked the operation here?
    Any ideas would be appreciated.

    note-----------------------------------
    The test board has GPIO wiring for MII, but will it work if we change to GPIO wiring for RMII?
    If it can work, we will change it and check it.
    ----------------------------------------

    best regard.

  • Hi Gouki Ono,

    It's good to hear about this progress on your side. I have some additional thoughts if it's just RMII mode that isn't working 100% now.

    1. Are DP83822I device registers configured properly for RMII mode with proper clocking? I may even suggest creating a new post on the TI Interface E2E forum so the DP83822I experts can help identify things to check.
    2. Can you try with using C2000 50MHz Internal Clock? Seems our SW examples use the internally generated clock instead of external through ENET_RMII_CLK pin. Just something to quickly try if there is some difference.

    note-----------------------------------
    The test board has GPIO wiring for MII, but will it work if we change to GPIO wiring for RMII?
    If it can work, we will change it and check it.

    I believe this should work if you use the internal clock, since RMII signal seem to be a subset of MII signals.

    Best,

    Kevin

  • Hi Kevin.

    I checked the test board in a 100-FULL/RMII configuration.
    As a result, the PHY loopback on the test board had a success rate of 100%.
    The communication on the custom board and the test board was also the same behavior as MII.

    It is very likely that the custom board we have is badly designed.
    I'm planning to have the hardware designer check for pulse drift.

    I don't think there is a problem, but I want to make sure that there are no setting mistakes.
    Can I have a sample of the 100-FULL setting?

    thank you for your cooperation.
    best regard

  • Hi Kevin.

    After reassembling the power supply and LAN cable on the test board, the PHY may return "11111111" on the MDIO read.
    At the same time, the link is not recognized even though it is configured correctly.
    Since the link can be established, the configuration seems to be correct.

    There may be a problem with the RJ45 or the board.
    I also tried "MII/RMII PHY loopback" on the test board, but it gives a CRC error as well as the custom board.

    A new test board will arrive at the end of next week.
    I will recheck the MII/RMII with it.

    Best regards.

  • Hi Gouki Ono,

    Can I have a sample of the 100-FULL setting?

    By 100-FULL are you meaning for full-duplex? I haven't figured out if we have some config prepared to share yet.

    Since the link can be established, the configuration seems to be correct.

    There may be a problem with the RJ45 or the board.
    I also tried "MII/RMII PHY loopback" on the test board, but it gives a CRC error as well as the custom board.

    A new test board will arrive at the end of next week.
    I will recheck the MII/RMII with it.

    I thought you had run the PHY loopback on the test board (TMDSCNCD28388D) and saw a success rate of 100% previously. Are you experiencing some issues with it now?

    Let us know how you further testing goes.

    Best,

    Kevin

  • Hi Kevin.

    Here is the sample we are requesting.

    This is a sample that worked on 100BASE-Tx (100Mbps/Full-Duplex) using C2000Ware's "ethernet.c/ethernet.h".
    (Configuration running on a test board).

    If you can loopback EMAC, no problem.
    Other than that, there is no problem with any other functions.
    I'm wondering, "Is my setup wrong and I'm getting bad communication?" I would like to check, so I am asking for a sample.


    I have a test board in my possession, and at first it worked fine at 100Mbps/Full-Duplex.
    However, it is now in the following state.
    - MDIO from PHY sometimes returns abnormal values (0x11111111)
    - Sometimes no data is returned even after putting in the PHY loopback settings
    - Link-up does not occur even after putting in the necessary settings for link-up. Link-up may occur when power is turned on and off.

    When the source code of the Ethernet section of the test board is ported to the custom board, none of the above phenomena occur.
    When I do PHY Loopback at 100Mbps/Full-Duplex in this state, it is 91% successful.

    The period of normal operation at 100Mbps/Full-Duplex was so short that I am not sure myself if it was really working.
    When the new test board arrives, I would like to check again to see if it really works.

    Best regards

  • Hi Kevin.


    I have just received a new substrate and tested it under the same conditions.
    The test results are as follows: Sending/receiving 1518 bytes of Ether once every 5msec.


    Test Results
    ==============================================================
    Testboard TX --(MII)---> dp83822i --(100M/Full)--> dp83822i --(RMII)--> Customboard RX
    "10000 cnt, 10000 success"

    Testboard TX --(RMII)--> dp83822i --(100M/Full)--> dp83822i --(RMII)--> Customboard RX
    "10000 cnt, 10000 success"

    Customboard TX -(RMII)-> dp83822i --(100M/Full)--> dp83822i --(MII)---> Testboard RX
    "10000 cnt, 2291 success"

    Customboard TX -(RMII)-> dp83822i --(100M/Full)--> dp83822i --(RMII)--> Testboard RX
    "10000 cnt, 2275 success"


    PHY Loopback
    ==============================================================
    Testboard TX <--(MII)---> dp83822i (MII Loopback)
    "10000 cnt, 9011 success"

    Testboard TX <--(RMII)--> dp83822i (MII Loopback)
    "10000 cnt, 8969 success"

    Customboard TX <-(RMII)-> dp83822i (MII Loopback)
    "10000 cnt, 1950 success"
    ==============================================================


    As per the result I wrote last time, 10000 success if the test board is transmitting and the custom board is receiving.

    Last time, the test board's PHY Loopback was "10000 cnt, 10000 success", but this confirmation may have been wrong.
    The new board's Loopback results show 90% success and 10% failure.

    Is this what TI expects from the loopback results?
    If not, there may still be a mistake in the source code.
    Please give me a sample code.

  • Hi Gouki Ono,

    By test board, do you mean the control card or is it also a custom board? 

    Also, which loopback example did you run? Is it 'ethernet_ex1_basic_tx_rx_loopback' example?

    Best Regards

    Siddharth 

  • Hi, Siddharth.

    Do you not see the Replay above?
    Do you not understand how to write (100M/Full)?

    The test board is the control card.
    As described in the Replay above, it is a combination of MCU063B and TMDSHSECDOCK(rev.F).
    I am saying that the problem is that there is a 10% failure in this test environment with "Loopback of 100Base_Tx".

    It is not a sample of any loopback.
    As I have written many times, there is not a single 100Base_Tx (Full-Duplex) loopback sample in TI's C2000ware.
    So I have repeatedly requested a "sample communicating at 100Base_Tx".
    I have also provided a complete set of my projects.
    Sample location "C:\ti\c2000\c2000Ware_4_01_00_00\driverlib\f2838x\examples\cm\ethernet"

    This question has taken a month to answer.
    Is it about time you provided a sample that communicates/loops back over 100Base_Tx?

  • Investigated PHY Loopback in other settings on the test board. The source has not been changed except for the corresponding setting part.

    - Once every 5msec, size 1518byte, 10Base_Tx, Full-Duplex, PHY Loopbackcontrol card.
    10000Cnt, 10000Success.

    - Once every 5msec, size 1518byte, any speed, Half-Duplex, PHY-Loopback, control card.
    10000Cnt, 0Success.

    I tried it because the specification has the following description.
    - Do not loop back big packets. Big packets may get corrupted in the loopback FIFO.

    Once every 5msec, size 500byte, 100Base_Tx, Full-Duplex, PHY Loopbackcontrol card.
    10000 Cnt, 9300 Success.

  • Hi, 

    Please try with the attached code .  Replace this file with the one in the ethernet_ex1_basic_tx_rx_loopback example of C2000Ware.

    Have tried loopback (MII) with the control card and see no packet loss. 

    //#############################################################################
    //
    // FILE:   ethernet_ex1_basic_tx_rx_loopback.c
    //
    // TITLE:  Ethernet Basic Transmit and Receive MAC Loopback Example
    //
    //! \addtogroup driver_example_cm_list
    //! <h1> Ethernet MAC Internal 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 MAC Loop back mode
    //! Prepares a packet to be sent, Sends the packet and reads the statistics
    //! 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 Internal Loop back mode
    //! and hence needs no external connection on the MII Data lines.
    //! But it needs the MII Tx and Rx clocks to be input on those pins
    //! 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
    //!  - None
    //!
    //
    //#############################################################################
    //
    //
    // $Copyright:
    // Copyright (C) 2022 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   2U
    //
    //Change this define for changing Packet buffer length
    //
    #define ETHERNET_MAX_PACKET_LENGTH 1538U
    
    
    
    //
    // Globals
    //
    uint8_t pData[PACKET_LENGTH];
    //
    // Globals
    //
    uint8_t Ethernet_rxBuffer[ETHERNET_NO_OF_RX_PACKETS *
                              ETHERNET_MAX_PACKET_LENGTH];
    
    //
    // Main
    //
    void main(void)
    {
        Ethernet_InitInterfaceConfig initInterfaceConfig;
        Ethernet_InitConfig *pInitCfg;
        Ethernet_Pkt_Desc pktDesc;
        uint32_t i,loopCount=1000;
        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 if (j==1)
    //             HWREG((uint32_t *)pData +i) = 0x11111111;
            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;
           // initInterfaceConfig.phyMode = ETHERNET_SS_PHY_INTF_SEL_RMII;
          //  initInterfaceConfig.clockSel = ETHERNET_SS_CLK_SRC_INTERNAL;
    
            //
            //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);
            pInitCfg->chInfo[0][0].burstLength = 1;
            //
            // Get an initial configuration of known good parameters
            //
            Ethernet_getInitConfig(pInitCfg);
    
            //
            //Configure the Loopback mode
            //
            pInitCfg->loopbackMode = ETHERNET_MAC_CONFIGURATION_LM_LOOPBACK_ENABLED;
    
            pInitCfg->pktMTU = 1536;
            //
            //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);
            //
    
            //
            // Clear the statistics
            //
            stats.txPacketCountGood = 0 ;
            stats.rxUnicastPacketsGood = 0;
    
            //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);
    
            //
            //Prepare a Packet Descriptor structure to send a packet
            //This contains a single buffer 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;
    
            //
             //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 Loopback
             //
             phyRegContent |= 0x4000;
    
             Ethernet_writePHYRegister(EMAC_BASE,0,phyRegContent);
    
             //
             //Bit 13 of BMCR configures the speed -configure for 100 Mbps
             //
             phyRegContent |= 0x2000;
             Ethernet_writePHYRegister(EMAC_BASE,0,phyRegContent);
    
             //
             //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);
    
             /* linkSpeed ( MAC_Configuration Register "FES" ) */
             //Ethernet_clearMACConfiguration( EMAC_BASE, ((uint32_t)1 << 14) ); // EMAC 10Mbps
             Ethernet_setMACConfiguration( EMAC_BASE, ((uint32_t)1 << 14) );   // EMAC 100Mbps
    
             Ethernet_setMACConfiguration( EMAC_BASE, ((uint32_t)1 << 13) );   // EMAC Full Duplex
          //   Ethernet_clearMACConfiguration( EMAC_BASE, ((uint32_t)1 << 13) ); // EMAC Half Duplex
    
            //
               //Send the packet prepared
               //
               i=0;
               while(i<loopCount)
               {
                   //
                   //Prepare a Packet Descriptor structure to send a packet
                   //This contains a single buffer 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;
                   pktDesc.pktChannel = ETHERNET_DMA_CHANNEL_NUM_0;
                   pktDesc.pktLength = PACKET_LENGTH;
                   pktDesc.validLength = PACKET_LENGTH;
                   pktDesc.numPktFrags = 1;
    
                   Ethernet_sendPacket(emac_handle,&pktDesc);
    
                   //
                   //Delay for the MAC to send the packet on the wire and receive it
                   //
                   SysCtl_delay(3000000);
    
                   //
                   //Read the statistics of the Module
                   //
                   Ethernet_getStatistics(emac_handle, &stats);
                   i++;
                   pData[7] = i;
               }
            //
            //Check if a packet has been received
            //
            if(!stats.rxUnicastPacketsGood)
                 __asm("   bkpt #0");
        
    }
    
    
    

    Best Regards

    Siddharth

  • Thank you for your response.

    I checked the source code you provided, and it shows EMAC loopback enabled, which appears to be only a 100% successful loopback inside EMAC, not a confirmation of the PHY loopback.

    //Configure the Loopback mode
    //pInitCfg->loopbackMode = ETHERNET_MAC_CONFIGURATION_LM_LOOPBACK_ENABLED;
    pInitCfg->loopbackMode = ETHERNET_MAC_CONFIGURATION_LM_LOOPBACK_DISABLED; // need

  • Hi, 

    I tried it out by disabling the EMAC Loopback. In this case, had to increase the delay between the send packet function call to get 100% success. 

    Changed the  delay to "SysCtl_delay(5000000); "

    Best Regards

    Siddharth

  • It is necessary to execute the above test with 500 bytes and 16 or more RX buffers.

    #define PACKET_LENGTH 500
    //#define PACKET_LENGTH 132
    
    //#define ETHERNET_NO_OF_RX_PACKETS   2U
    #define ETHERNET_NO_OF_RX_PACKETS   16U

    I tested with the above settings.
    [500byte]============================
    stats.tx1024toMaxOctetsPacketsGood = 500500
    stats.txPacketCountGoodBad = 500500
    stats.rx1024toMaxOctetsPacketsGood = 294
    stats.rxPacketCountGoodBad = 294
    =====================================

    Since the maximum Etherframe is 1518 bytes
    What you actually need is a test of 1504 bytes.

    ----------------------------------------------------------------------------------------

    test details
    ・The number of buffers used for reception on Ethernet is all determined by Ethernet.h.
    ・In the case of the library standard, 16 buffers are required for EMAC reception. (ETHERNET_DESCRIPTORS_NUM_RX)
    ・In the reception of the library, "request the descriptor of the next buffer when reception is completed", so if you want to do something after reception, let the reception process only judge in order not to stop the DMA interrupt, and touch the buffer elsewhere Register extra buffers for shape. Therefore, you need twice as many RX buffers as specified. (If you plan to process 1500 bytes within a DMA interrupt, 16 is fine.)

    When setting the above, the buffer size exceeds the capacity of RAM, so please set additional RAM on the memory map.
    .bss location.

  • One additional note.
    I do not consider "PHY Loopback not succeeding 100% of the time" on the control card to be a problem.
    I am asking because I am not sure if this is TI's intended behavior or not.

    The specification also states the following, and given that it doesn't say anything specific
    In fact, a 500-byte loopback may also fall under the "big packets" category.
    - Big packets may get corrupted in the loopback FIFO.

    In TI's opinion, 1500 byte loopback is not a problem if it "can always fail".
    (If you have two units and there is a 10% packet loss in sending and receiving, then it is a problem.)

  • Hi, 

    I tried the same test with packet length of 500 bytes and 16 Rx buffers.  In this case, had to increase the delay between the send packet function call to get 100% success.  Changed the  delay to "SysCtl_delay(6000000); "

    I think there has to be sufficient time delay in between the packers to send and receive the packets successfully. 

    Best Regards

    Siddharth

  • As I confirmed in the last replay.
    I checked the time of "SysCtl_delay(5000000);" with an oscilloscope and found it to be 160msec.

    It is unusual that an interval of 160 msec is needed to send 132 bytes over Ethernet.
    Please stop the investigation to increase the time and do a fundamental investigation of the library.

  • Hi, 

    Request you to provide the following information

    • Register dump for PHY from 0x0000 to 0x001E ,  pease read these registers multiple times (at least 5 times)
    • If the link partner also has DP83822 PHY in it, please provide the similar register dump as requested above

    This will help in figuring out if there is any issue with the PHY configuration/. 

    Apart from this . we are analyzing the buffer management  (packet length and number of RX buffers/descriptors ) and will get back to you.

    Best Regards

    Siddharth

  • What is this request about?

    Are you talking about the control card's loopback failing?
    Are you talking about "100MHz/Full communication on a custom board fails"?

    With Loopback, you don't need an opposing device.
    I assume you are talking about the PHY registers on the custom board.

    ===============================================

    mdio.zip

    ===============================================

    Random sampling during communication.

    PS
    We have two custom boards, but only one is connected to UART, so both Sender/Receiver are the same machine.

    Basically the same structure and software.

  • Hi,

    Thanks for sharing the file. Yes, it is for 100MHz/Full communication with the custom board.

    There are few status registers on the PHY which  indicate the link status and other information which can help in narrowing down on the cause of this issue.

    Best Regards

    Siddharth

  • Hi Gouki,

    Thank you for sharing the register dump files, I went through the register dump files of both the Transmitter and Receiver.

    Both are in RMII mode, and the reference clock is 25MHz.

    Did you face packet drop issues on the Receiver end, when you were sampling the above register dumps?

    Looking through the Receiver Register 0x0017 bit [2] of DP83822, the RMII Underflow Status bit is being triggered. Which indicates RMII RX FIFO Underflow detection.

    RMII includes a programmable elastic buffer to adjust for the frequency differences between the reference clock and the recovered receive clock. The programmable elastic buffer minimizes internal propagation delay based on expected maximum packet size and clock accuracy.

    The below table indicates how to program the FIFO buffer (Register 0x0017, bits[1:0]) based on the expected maximum packet size and clock accuracy:

    More details about this register are available in the datasheet:

    https://www.ti.com/lit/ds/symlink/dp83822i.pdf?ts=1670368178757&ref_url=https%253A%252F%252Fwww.google.com%252F

    Please try adjusting this FIFO buffer values and see if you are still noticing any RMII Overflow/ Underflow Status being triggered (Register 0x0017).

    Regards,
    Rahul

  • Hi Rahul.

    Sorry, resolved is wrong.

    The default setting "b01" causes Underflow.
    After checking, "b10" causes neither Overflow nor Underflow, so I decided to set "b10".


    We tried the following four communication patterns.
    =======================================
    Sent 10,000 times, received 10,000 times

    0x0017 : 00000000 01100011
    (EMAC statistics)
    rxPacketsCountGoodBad = 8989
    rxCRCErrorPackets = 7520
    rxUnicastPacketsGood = 1469

    0x0017 : 00000000 01100010
    (EMAC statistics)
    rxPacketsCountGoodBad = 8892
    rxCRCErrorPackets = 7495
    rxUnicastPacketsGood = 1397

    0x0017 : 00000000 01100101
    (EMAC statistics)
    rxPacketsCountGoodBad = 8959
    rxCRCErrorPackets = 7476
    rxUnicastPacketsGood = 1483Hi.

    0x0017 : 00000000 01100000
    (EMAC statistics)
    rxPacketsCountGoodBad = 8942
    rxCRCErrorPackets = 7472
    rxUnicastPacketsGood = 1470
    =======================================

    Unfortunately, this does not seem to solve the reception problem.

  • I want to delete the resolved...

  • What is the current situation?

    I can't explain anything about your query until I get some information. Please just give me some information on whether it is being tested or not.

  • Hi, 

    We are still looking into it .  We looked into the waveform that you had sent over email where there is a synchronization issue between RX_D1 and REF_CLK which might be causing this issue.  Instead of using an external clock , request  you to try with the internal 50-MHz clock for RMII. 

    The below snapshots are from the TRM for ethernet module and RMII mode

      

    Rahul, 

    If there is any other PHY configuration that needs to be done, please advise.

    Best Regards

    Siddharth

  • Hi Siddharth.

    Acknowledged as being under investigation.

    I have contacted you before, but when the internal clock is set to RMII, it succeeds about 70% of the time. However, we have determined that 30% packet loss is not usable for communication.

  • Hi, 

    Are you seeing the clock sync issue even while using the internal clock? 

    Rahul, 

    If there is any other PHY configuration that needs to be done or checked, please advise.

    Best Regards

    Siddharth

  • I am not sure if using the CPU's internal clock is causing the same phenomenon since there is no way to check the CLK and therefore no way to check if they are in sync.

    However, as I mentioned above, even when operating with the internal clock, the 100M-Full reception is only about 70% successful.

  • Hi, 

    Need a clarification on your response .  You mentioned 30% packet loss -  Is it CRC errors or packets not received at all?

    Best Regards

    Siddharth

  • Statistics when EMAC is run with internal clock.
    ===============================================
    The test conditions are
    - Transmitted 10,000 times, received 10,000 times
    - 100Base_Tx
    - 1518byte
    - Full-Duplex
    - once every 5 ms

    rxPacketsCountGoodBad = 9296
    rxOctetCountGoodBad = 14109777
    rxOctetCountGood = 9271944
    rxCRCErrorPackets = 1657
    rxAlignmentErrorPackets = 1531
    rx1024toMaxOctetsPacketsGoodBad = 9296
    rxUnicastPacketsGood = 6108
    ===============================================


    The following is the source code that was changed to make the internal clock work.
    ===============================================
    Ethernet_InitInterfaceConfig initInterfaceConfig;
    Ethernet_InitConfig *pInitCfg;

    initInterfaceConfig.clockSel = ETHERNET_SS_CLK_SRC_INTERNAL;
    pInitCfg->emacSSConfig.clkSrcSel = ETHERNET_SS_CTRLSTS_CLK_SRC_SEL_INTERNAL;
    ===============================================

  • Hi, 

    Are you seeing the same behavior if the packet size is smaller?  Do you observe CRC/Alignment errors with smaller packet size?

    Request you to share  RX_D1 and REF_CLK waveform while sending large size packets and small size packets .

    Best Regards

    Siddharth

  • Statistics of 200 bytes sent and received.
    ===============================================
    The test conditions are
    - Transmitted 10,000 times, received 10,000 times
    - 100Base_Tx  Full-Duplex
    - 200byte
    - RMII
    - EMAC Clock = output PHY Clock 50Mhz
    - once every 5 ms

    rxPacketsCountGoodBad = 9038
    rxOctetCountGoodBad = 1843752
    rxOctetCountGood = 1623228
    rxCRCErrorPackets = 1081
    rx128to255OctetsPacketsGoodBad = 9038
    rxUnicastPacketsGood = 7957
    ===============================================

    Please wait for waveform output

  • This is the waveform of a successful reception of 200 bytes.

  • Hi, 

    Have shared the waveform with the PHY expert to take a look and provide his inputs.

    Best Regards

    Siddharth