DRA829J: MDIO errata i2329

Part Number: DRA829J

Tool/software:

Hello All,
I was implementing the MDIO PHY read and write functionalities considering the work around of errata I2329.
In the TI PDK implementation of this errata, it is found that after writing or reading the PHY register, there is wait time for pull-up to work in the code as shown below

Code from the funcion CpswMdio_manualPhyRegWrite22

Code from the function 
CpswMdio_manualPhyRegRead22

    
I see the MDIO clock is pulled down for 3 times for writing and 2 times for reading. Please give more insight about this.
What is the minimum time to wait for the write and read operations to be completed?

While going through another function CpswMdio_swFieldSend,
static void CpswMdio_swFieldSend(uint8 ctrlIdx,
                                 sint32 len,
                                 uint32 val,
                                 uint32 *manualIf)
{
    CSL_mdioHandle hMdioRegs = CpswMdio_getRegAddr();
    uint32 mdo;
    sint32 i;

    for (i = (len - 1); i >= 0; i--)
    {
        mdo = (val >> i) & 1U;
        /* prepare the value of MDIO_MANUAL_IF_REG register */
        /* Drive MDIO data line at MDIO clock falling edge */
        CSL_FINS(*manualIf, MDIO_MANUAL_IF_REG_MDIO_PIN, mdo);
        CSL_FINS(*manualIf, MDIO_MANUAL_IF_REG_MDIO_MDCLK_O, 0U);
        CpswMdio_setManualIf(hMdioRegs, *manualIf);

        /* MDIO write clock delay on low */
        Eth_GetMdioWriteLowDelayNsec(ctrlIdx);

        /* MDIO clock rising edge */
        CSL_FINS(*manualIf, MDIO_MANUAL_IF_REG_MDIO_MDCLK_O, 1U);
        CpswMdio_setManualIf(hMdioRegs, *manualIf);

        /* MDIO write clock delay on high */
        Eth_GetMdioWriteHighDelayNsec(ctrlIdx);
    }
}

What is the delay to be introduced between the falling edge and raising edge of the MDIO clock


Kind regards
Thank You
Manisha Narayana Gowda

  • Hi,

    I see the MDIO clock is pulled down for 3 times for writing and 2 times for reading. Please give more insight about this.

    Please refer to TI latest SDK 9.2.  Wait for pull-up is same in read/write.
    The transactions are as per MDIO clause22 protocol.

    I think you are referring to MCAL Eth implementation of MDIO manual mode.
    It has flexibility to configure the MDIO delay required as per Use-case of MDIO frequency via ETH configuration.

    Please refer to MCUSW Use Guide (refer section: Cpsw Mdio Errata i2329 Manual Mode Delay Math) for the MDIIO tuning parameters.

    Best Regards,
    Sudheer

  • Hello Sudheer,
    Acc. to my understanding, the writing operation takes places on the falling edge of the clock.


    How can the clock is set to 0 for the first time and again made to zero while writing?
    It looks bit strange because there will not be generation of any falling edge to send the data.
    Please explain this.

    Kind Regards
    Manisha Narayana Gowda

  • Hi,

    Acc. to my understanding, the writing operation takes places on the falling edge of the clock.

    Not exactly.
    Please refer to below. Writing the data during clock low and reading at clock high.
    https://en.wikipedia.org/wiki/Management_Data_Input/Output#:~:text=MDIO%20Packet%20Format%20(clause%2022),-MDIO%20Packet%20Format&text=The%20Start%20field%20consists%20of,contains%20the%20combination%20'01'.&text=The%20Opcode%20consists%20of%202,'%20or%20write%20'01'.&text=5%20bits%2C%20PHY%20address.

    How can the clock is set to 0 for the first time and again made to zero while writing?
    It looks bit strange because there will not be generation of any falling edge to send the data.
    Please explain this.

    If we keep data in falling edge or during clock low, The read will be at clock High.

    The Manual mode implementation is proper, we have validated it on TI EVM an even many customers also using on their custom boards.

    Best Regards,
    Sudheer

  • Hi,
    "If we keep data in falling edge or during active low, The read will be at clock active." This sentence is not clear . Please explain in detail. I really need to understand before I implement the workaround.
    Please take a look at the below code 

    static Std_ReturnType CpswMdio_manualPhyRegRead22(uint8 ctrlIdx,
                                                      uint32 phyAddr,
                                                      uint32 regNum,
                                                      uint16 *val)
    {
        CSL_mdioHandle hMdioRegs = CpswMdio_getRegAddr();
        Std_ReturnType retVal = E_OK;
        uint32 manualIf;
        uint32 ack;
    
        manualIf = CpswMdio_getManualIf(hMdioRegs);
    
        /* Disable PHY interrupt driver */
        CSL_FINS(manualIf, MDIO_MANUAL_IF_REG_MDIO_MDCLK_O, 0U);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
    
        /* Enable our drive capability */
        CSL_FINS(manualIf, MDIO_MANUAL_IF_REG_MDIO_OE, 1U);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
    
        /* Send 32-bit preamble */
        CpswMdio_swFieldSend(ctrlIdx, CPSW_MDIO_PRE32_LEN, CPSW_MDIO_PRE32_BITS, &manualIf);
    
        /* Issue clause 22 MII read function {0,1,1,0} */
        CpswMdio_swFieldSend(ctrlIdx, CPSW_MDIO_ST_OP_LEN, CPSW_MDIO_READ_FUNC, &manualIf);
    
        /* Send the device number MSB first */
        CpswMdio_swFieldSend(ctrlIdx, CPSW_MDIO_PA5_LEN, phyAddr, &manualIf);
    
        /* Send the register number MSB first */
        CpswMdio_swFieldSend(ctrlIdx, CPSW_MDIO_RA5_LEN, regNum, &manualIf);
    
        /* Send turn-around cycles */
        CSL_FINS(manualIf, MDIO_MANUAL_IF_REG_MDIO_OE, 0U);
        CpswMdio_swToggleMdclkWrite(ctrlIdx, &manualIf);
    
        /* Get PHY ack */
        ack = CpswMdio_readMdi(hMdioRegs);
        CpswMdio_swToggleMdclkRead(ctrlIdx, &manualIf);
    
        if (ack == 0U) /* If acked read the data */
        {
            *val = CpswMdio_swFieldRecv(ctrlIdx, CPSW_MDIO_D16_LEN, &manualIf);
            retVal = E_OK;
        }
        else
        {
            *val = CpswMdio_swFieldDiscard(ctrlIdx, CPSW_MDIO_D16_LEN, &manualIf);
            retVal = E_NOT_OK;
        }
    
        /* Give time for pull-up to work */
        CSL_FINS(manualIf, MDIO_MANUAL_IF_REG_MDIO_MDCLK_O, 0U);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
    
        /* Re-enable PHY interrupt function */
        CpswMdio_swToggleMdclkWrite(ctrlIdx, &manualIf);
    
        return retVal;
    }
    
    static void CpswMdio_swFieldSend(uint8 ctrlIdx,
                                     sint32 len,
                                     uint32 val,
                                     uint32 *manualIf)
    {
        CSL_mdioHandle hMdioRegs = CpswMdio_getRegAddr();
        uint32 mdo;
        sint32 i;
    
        for (i = (len - 1); i >= 0; i--)
        {
            mdo = (val >> i) & 1U;
    
            /* Drive MDIO data line at MDIO clock falling edge */
            CSL_FINS(*manualIf, MDIO_MANUAL_IF_REG_MDIO_PIN, mdo);
            CSL_FINS(*manualIf, MDIO_MANUAL_IF_REG_MDIO_MDCLK_O, 0U);
            CpswMdio_setManualIf(hMdioRegs, *manualIf);
    
            /* MDIO write clock delay on low */
            Eth_GetMdioWriteLowDelayNsec(ctrlIdx);
    
            /* MDIO clock rising edge */
            CSL_FINS(*manualIf, MDIO_MANUAL_IF_REG_MDIO_MDCLK_O, 1U);
            CpswMdio_setManualIf(hMdioRegs, *manualIf);
    
            /* MDIO write clock delay on high */
            Eth_GetMdioWriteHighDelayNsec(ctrlIdx);
        }
    }

    In the function CpswMdio_manualPhyRegRead22 at the line 14, the clock is set to low. Then there is a call of the function CpswMdio_swFieldSend inside which (line 79 in the above code snippet) the clock is set to low again. Why the clock is set to active low for 2 times continuously?

  • Hi,

    "If we keep data in falling edge or during active low, The read will be at clock active." This sentence is not clear . Please explain in detail. I really need to understand before I implement the workaround.

    Sorry for confusion.
    I mean we are wiring data during clock low, and reading the data at clock high.

    In the function CpswMdio_manualPhyRegRead22 at the line 14, the clock is set to low. Then there is a call of the function CpswMdio_swFieldSend inside which (line 79 in the above code snippet) the clock is set to low again. Why the clock is set to active low for 2 times continuously?

    It will be for to sending the data we need to handle clock toggling (low & high), so the whole read sequence creating twice setting clock low in regular flow and send filed function.
    As clock is already low, it will not hard setting low again, also these continuous statements the duration could be in nsec only.

    Best Regards,
    Sudheer

  • Hi Sudheer, 

    Thanks for the quick reply,
    It is still not clear to me that if the MDIO data is captured at falling edge of the clock or raising edge. 

    "I mean we are wiring data during clock low, and reading the data at clock high." but the data can either get sampled on raising edge or falling edge basically. How does it happen in this case.

    Regarding the CpswMdio_manualPhyRegRead22

    static Std_ReturnType CpswMdio_manualPhyRegRead22(uint8 ctrlIdx,
                                                      uint32 phyAddr,
                                                      uint32 regNum,
                                                      uint16 *val)
    {
        CSL_mdioHandle hMdioRegs = CpswMdio_getRegAddr();
        Std_ReturnType retVal = E_OK;
        uint32 manualIf;
        uint32 ack;
    
        manualIf = CpswMdio_getManualIf(hMdioRegs);
    
        /* Disable PHY interrupt driver */
        CSL_FINS(manualIf, MDIO_MANUAL_IF_REG_MDIO_MDCLK_O, 0U);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
    
        /* Enable our drive capability */
        CSL_FINS(manualIf, MDIO_MANUAL_IF_REG_MDIO_OE, 1U);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
    
        /* Send 32-bit preamble */
        CpswMdio_swFieldSend(ctrlIdx, CPSW_MDIO_PRE32_LEN, CPSW_MDIO_PRE32_BITS, &manualIf);
    
        /* Issue clause 22 MII read function {0,1,1,0} */
        CpswMdio_swFieldSend(ctrlIdx, CPSW_MDIO_ST_OP_LEN, CPSW_MDIO_READ_FUNC, &manualIf);
    
        /* Send the device number MSB first */
        CpswMdio_swFieldSend(ctrlIdx, CPSW_MDIO_PA5_LEN, phyAddr, &manualIf);
    
        /* Send the register number MSB first */
        CpswMdio_swFieldSend(ctrlIdx, CPSW_MDIO_RA5_LEN, regNum, &manualIf);
    
        /* Send turn-around cycles */
        CSL_FINS(manualIf, MDIO_MANUAL_IF_REG_MDIO_OE, 0U);
        CpswMdio_swToggleMdclkWrite(ctrlIdx, &manualIf);
    
        /* Get PHY ack */
        ack = CpswMdio_readMdi(hMdioRegs);
        CpswMdio_swToggleMdclkRead(ctrlIdx, &manualIf);
    
        if (ack == 0U) /* If acked read the data */
        {
            *val = CpswMdio_swFieldRecv(ctrlIdx, CPSW_MDIO_D16_LEN, &manualIf);
            retVal = E_OK;
        }
        else
        {
            *val = CpswMdio_swFieldDiscard(ctrlIdx, CPSW_MDIO_D16_LEN, &manualIf);
            retVal = E_NOT_OK;
        }
    
        /* Give time for pull-up to work */
        CSL_FINS(manualIf, MDIO_MANUAL_IF_REG_MDIO_MDCLK_O, 0U);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
        CpswMdio_setManualIf(hMdioRegs, manualIf);
    
        /* Re-enable PHY interrupt function */
        CpswMdio_swToggleMdclkWrite(ctrlIdx, &manualIf);
    
        return retVal;
    }
    

    The value of the MDIO_PIN is used to acknowledge the reception of the data (line 39 in the above code). Please correct me if I am wrong. In the following function CpswMdio_swFieldRecv

    static uint16 CpswMdio_swFieldRecv(uint8 ctrlIdx,
                                       sint32 len,
                                       uint32 *manualIf)
    {
        CSL_mdioHandle hMdioRegs = CpswMdio_getRegAddr();
        uint32 mdi;
        uint16 val;
        sint32 i;
    
        val = 0U;
    
        for (i = (len - 1); i >= 0; i--)
        {
            mdi = CpswMdio_readMdi(hMdioRegs);
            val |= ((uint16)mdi & 1U) << i;
            /* MDIO read with clock delay */
            CpswMdio_swToggleMdclkRead(ctrlIdx, manualIf);
        }
    
        return val;
    }
    

    In the line 5 hMdioRegs holds the value 0x8000f00U. What this value is?
    Please explain from where (which register of MDIO or PIN) the data is read from.

  • Hi, 

    It is still not clear to me that if the MDIO data is captured at falling edge of the clock or raising edge. 

    MDIO Data pin write sample at clock low. 

    Read will be at clock high. 

    The value of the MDIO_PIN is used to acknowledge the reception of the data (line 39 in the above code). Please correct me if I am wrong. In the following function CpswMdio_swFieldRecv

    Yes, after acknowledgement from phy will be reading the data. 

    Please refer to above shared wiki page for more detals about mdio c22 protocol. 

    In the line 5 hMdioRegs holds the value 0x8000f00U. What this value is?
    Please explain from where (which register of MDIO or PIN) the data is read from

    It should be MDIO_MANUAL_IF_REG.

    Please check TRM and register details for more information. 

    Best Regards, 

    Sudheer

  • Thanks for your answer.
    Th address of the MDIO_MANUAL_IF_REG is not 0x8000f00U. Hence the question was asked. It is not clear.

  • Hi,

    Is there any example to refer the MDIO initialization in manual mode? How can PHY be alive and linked in this mode.

    In case of MDIO Manual Mode, PHY Alive & Link status are getting by reading the PHY registers.

    In case of STATECHANGE/NORAML Mode, it will be by reading the MDIO Alive & Link status registers.

    Please refer to below, Alive request reading the PHY register in case of manual mode.


    Best Regards,
    Sudheer

  • My MDIO initialization function includes setting the CPSW_MDIO_POLL_REG:MANUALMODE. But I cannot see PHY is alive by reading the BMSR register. Is there any other initialization require in manual mode for PHY to be alive and linked?

  • Hi,

    . But I cannot see PHY is alive by reading the BMSR register. Is there any other initialization require in manual mode for PHY to be alive and linked?

    No need of other configurations, PHY related configuration to be care like registers settings and PHY address.
    Also, check is PHY is out of reset or not? 
    May I know which SDK version you are using? Can you check with latest TI SDK 9.2.

    Best Regards,
    Sudheer

  • Thanks for ur answer. I am using the latest veriosn 9.2.

  • Hi,

    Thanks for ur answer. I am using the latest veriosn 9.2.

    Thanks for the confirmation. 

    . But I cannot see PHY is alive by reading the BMSR register. Is there any other initialization require in manual mode for PHY to be alive and linked?

    No need of other configurations, PHY related configuration to be care like registers settings and PHY address.
    Also, check is PHY is out of reset or not? 

    Can you please check above points once.
    Also, note that MDIO Manual mode doesn't support C45 only C22 was supported. If your PHY can't support C22 then it will not communicate in Manual Mode.

    Best Regards,
    Sudheer

  • Thanks for your answer.

    static uint16 CpswMdio_swFieldRecv(uint8 ctrlIdx,
                                       sint32 len,
                                       uint32 *manualIf)
    {
        CSL_mdioHandle hMdioRegs = CpswMdio_getRegAddr();
        uint32 mdi;
        uint16 val;
        sint32 i;
    
        val = 0U;
    
        for (i = (len - 1); i >= 0; i--)
        {
            mdi = CpswMdio_readMdi(hMdioRegs);
            val |= ((uint16)mdi & 1U) << i;
            /* MDIO read with clock delay */
            CpswMdio_swToggleMdclkRead(ctrlIdx, manualIf);
        }
    
        return val;
    }
    static inline CSL_mdioHandle CpswMdio_getRegAddr(void)
    {
        return (CSL_mdioHandle)Eth_Cpsw_GetMdioRegAddr();
    }
    
    
    #define Eth_Cpsw_GetMdioRegAddr()                                          ( 0x8000f00U )

    In the above function 
    I read the data on the MDIO_PIN and it is always 1. But according to the above code the data is read from other register. It is not the address of  CPSW_MDIO_MANUAL_IF_REG. Please explain about this.


  • Hi,

    I read the data on the MDIO_PIN and it is always 1. But according to the above code the data is read from other register. It is not the address of  CPSW_MDIO_MANUAL_IF_REG. Please explain about

    The address defined in your case was wrong.
    #define Eth_Cpsw_GetMdioRegAddr()                                          ( 0x8000f00U )

    Please refer to below Eth configuration data from SDK for CPSW2G.


    Best Regards,
    Sudheer

  • Thanks for your reply, I am able to see the MDIO frame . But after the start operation code "01" for write operation I send the code "01". But the in the operation section of the frame shown unknow. The value is sent just like in TI pdk. How can this be resolved


  • Hi,

    But after the start operation code "01" for write operation I send the code "01". But the in the operation section of the frame shown unknow. The value is sent just like in TI pdk. How can this be resolved

    We are sending Start & Opcode (Read/write) together, means in same send request will be sending 4 bits (2 bits start and 2 bits opcode)
    Can you try to use as in TI SDK and check.

    Best Regards,
    Sudheer

  • Can you please let me know what is the operation code for write and read. For reading I put "10" but read operation is happening with the code "11". For write operation I put 01 but I get the frame as unknow 

    Thanks

  • Hi,

    Can you please let me know what is the operation code for write and read. For reading I put "10" but read operation is happening with the code "11". For write operation I put 01 but I get the frame as unknow 

    Read opcode will be 10 and write opcode will be 01. The same was used in TI SDK and many customers are able to communicate with PHYs in Manual mode operation from TI SDK.

    Also, I could see some unknown in message. It should not be.

    Please refer to the link shared earlier, for the MIDO protocol.
    https://en.wikipedia.org/wiki/Management_Data_Input/Output#:~:text=MDIO%20Packet%20Format%20(clause%2022),-MDIO%20Packet%20Format&text=The%20Start%20field%20consists%20of,contains%20the%20combination%20'01'.&text=The%20Opcode%20consists%20of%202,'%20or%20write%20'01'.&text=5%20bits%2C%20PHY%20address

    Kindly check your side, any delay are being added, also make sure that no interrupt or process/task context during this MDIO operation.
    If any will delay the MDIO operation as it is handling by controlling MDIO pins.

    Best Regards,
    Sudheer

  • Hello,
    Thanks for your reply. In CpswMdio_manualPhyRegRead22 function, there is check for PHY acknowledgement. Can this be explained more?
    I implemented the read function where I check the MDIO_PIN. But the value of the pin is always read 1. The read function is called after writing to the same register from which the value has to be read.

    One more question regarding the PHY DP83822, I want to read the alive status of the PHY. Which register can be referred for this? I could not find alive status in the TRM. BMSR register do not have any bit to identify alive status acc to TRM but PDK reads this register in the function CpswMdio_isPhyAlive

    If the MDIO is configured to work under manual mode, can we still refer the  CPSW_MDIO_ALIVE_REG and CPSW_MDIO_LINK_REG to know about the alive and link status of the PHY?


    Kind Regards
    Thank You
    Manisha N G



  • Hi, 

    In CpswMdio_manualPhyRegRead22 function, there is check for PHY acknowledgement. Can this be explained more?

    Please refer to Wiki page shared above for the details of acknowledgement in mdio c22 protocol. 

    Phy will acknowledge for the read command and followed by data will be sent on mdio data line. 

    I implemented the read function where I check the MDIO_PIN. But the value of the pin is always read 1. The read function is called after writing to the same register from which the value has to be read.

    Phy has to toggle for the mdio pin as acknowledgement. 

    One more question regarding the PHY DP83822, I want to read the alive status of the PHY. Which register can be referred for this? I could not find alive status in the TRM. BMSR register do not have any bit to identify alive status acc to TRM but PDK reads this register in the function CpswMdio_isPhyAlive

    Will be checking the phy read transaction if transaction is sucess phy is alive, if not phy is not alive. 

    I think there is no specific alive status from phy. For more details please refer to spec. 

    If the MDIO is configured to work under manual mode, can we still refer the  CPSW_MDIO_ALIVE_REG and CPSW_MDIO_LINK_REG to know about the alive and link status of the PHY?

    No. These register will not hold the live status & Link status of phy. 

    Best Regards, 

    Sudheer

  • HI 

    Will be checking the phy read transaction if transaction is sucess phy is alive, if not phy is not alive. 

    I think there is no specific alive status from phy. For more details please refer to spec. 

    What is the use of this function in PDK "boolean CpswMdio_isPhyAlive(uint8 ctrlIdx, uint32 phyAddr)"? I see this function reads BMSR register which does not have alive status bit field

  • Hi, 

    What is the use of this function in PDK "boolean CpswMdio_isPhyAlive(uint8 ctrlIdx, uint32 phyAddr)"? I see this function reads BMSR register which does not have alive status bit field

    As mentioned above if PHY is responding for the mdio transaction, indicates phy is active and running. So, this function return the true as indication to phy is active (alive) 

    So, will be reading the BMSR register and expected to get some valid value not 0xFFFF.

    Best Regards, 

    Sudheer

  • Hi,
    Thanks for the information. When I initializes the MDIO in state change mode where I configure the control register (bit 30) ENABLE, (bit 20) PREAMBLE and (bit 0-15)CLKDIV I get the PHY alive and linked. If MDIO is initialized in MDIO manual mode I do not see the PHY alive (as you said I cannot execute the read operation)
    What can be the reason for PHY not alive in manual mode. I can see the data on logic analyzer when I send it via Write function in manual mode. But that data is probably not written to respective register of PHY as PHY is not alive
    Thanks
    Kind Regards
    Manisha N G

  • Hi, 

    What can be the reason for PHY not alive in manual mode. I can see the data on logic analyzer when I send it via Write function in manual mode. But that data is probably not written to respective register of PHY as PHY is not alive

    Probably the PHY is active only, the read transaction not be proper when you send manually. 

    For your reference, you can capture mdio transaction in STATECHANGE  mode and manual mode and check waveform difference for better understanding. 

    Best Regards, 

    Sudheer

  • Hello,
    PHY register value is not read well in my case though the implementation is same as in TI pdk. Is there any reference waveform in manual mode read operation?
    Thanks 
    Manisha N G

  • Hi,

    PHY register value is not read well in my case though the implementation is same as in TI pdk. Is there any reference waveform in manual mode read operation?

    Check how delay is configured in  PDK MDIO Manual Mode.

    Please refer to MCUSW Use Guide (refer section: Cpsw Mdio Errata i2329 Manual Mode Delay Math) for the MDIIO tuning parameters.

    For MCUSW please refer to above MCUSW User Guide for the MDIO tunning.

    Best Regards,
    Sudheer

  • Hi,

    Check how delay is configured in  PDK MDIO Manual Mode.

    Acc to TI Pdk Eth_GetMdioWriteLowDelayNsec is used to introduce the delay. 

    #define Eth_GetMdioWriteLowDelayNsec(CtrlIdx)  do { \
     } while(0)
    For MCUSW please refer to above MCUSW User Guide for the MDIO tunning.

    Where can I find the document?

  • Hi,

    For MCUSW please refer to above MCUSW User Guide for the MDIO tunning.

    Where can I find the document?

    Please refer to document from below Link.
    Please refer to MCUSW Use Guide (refer section: Cpsw Mdio Errata i2329 Manual Mode Delay Math) for the MDIIO tuning parameters.

    Best Regards,
    Sudheer

  • Hello,
    I have implemented the same delays suggested in TI  user guide. I get the corrupted data when I read the register back. On playing around with these delays, I also get the wrong reading values.  Seems like the proposed delays does not have any influence on the register values. It does not make any difference if I use the suggested delays in user guide or some dummy delays. Can you share me any working example code which has already been tested for authenticity,  which  I can refer to read and write to PHY registers?
    Can you also provide me the configuration of MDIO which were used during the testing of working around of errata i2329?


    I have attached image to know the corrupted data on using the delays in user guide.

  • Hi,

    make any difference if I use the suggested delays in user guide or some dummy delays. Can you share me any working example code which has already been tested for authenticity,  which  I can refer to read and write to PHY registers?
    Can you also provide me the configuration of MDIO which were used during the testing of working around of errata i2329?

    The MDIO Manual Mode code in SDK is already working for PHYs on TI EVM.

    IF MCUSW code is confusing about delay, you can use refer to PDK from RTOS SDK and use it for reference.

    If required, you can capture the data waveform while running in MDIO STATECHANGE Mode for both Read & Write.
    Also, same capture in case Manual Mode and compare both.

    Even as per code also, I could see above capture will be 0x1DC from the visible part.

    Best Regards,
    Sudheer

  • Can you also provide me the configuration of MDIO which were used during the testing of working around of errata i2329?

    What is the configuration of MDIO?

    Hello,
    I have implemented the same delays suggested in TI  user guide. I get the corrupted data when I read the register back. On playing around with these delays, I also get the wrong reading values.  Seems like the proposed delays does not have any influence on the register values. It does not make any difference if I use the suggested delays in user guide or some dummy delays. Can you share me any working example code which has already been tested for authenticity,  which  I can refer to read and write to PHY registers?
    Can you also provide me the configuration of MDIO which were used during the testing of working around of errata i2329?


    I have attached image to know the corrupted data on using the delays in user guide.

  • Even as per code also, I could see above capture will be 0x1DC from the visible part.

    But the value I sent is 0X1FE0

  • Hi,

    Even as per code also, I could see above capture will be 0x1DC from the visible part.

    But the value I sent is 0X1FE0

    Have you confirmed the same  in case of MDIO STATECHNAGE Mode instead of Manual Mode. This is to confirm, are there any bit fields which are Reserved.

    Also, can you please share the write capture as well.

    If required, you can capture the data waveform while running in MDIO STATECHANGE Mode for both Read & Write.
    Also, same capture in case Manual Mode and compare both.

    You can do above and compare the waveforms.


    Best Regards,
    Sudheer

  • Have you confirmed the same  in case of MDIO STATECHNAGE Mode instead of Manual Mode. This is to confirm, are there any bit fields which are Reserved.

    Have you confirmed the same  in case of MDIO STATECHNAGE Mode instead of Manual Mode. This is to confirm, are there any bit fields which are Reserved.

    This is the result in MDIO STATECHANGE . I cannot see the value sent. There are only read values and all are 0xffff. Comparison is not possible.

    Cannot see the value sent to PHY register. 

    Also, can you please share the write capture as well.


    This is the waveform for writing the data to PHY register.

  • Hi,

    Even as per code also, I could see above capture will be 0x1DC from the visible part.

    But the value I sent is 0X1FE0

    From above capture you are sending 0x3100 which is not the same as previous read & write transaction.

    If you need proper comparison, need same value write and read transaction is required in both MDIO STATECHANGE Mode and MANUAL Mode.

    It is very difficult to decode the waveform shared during STATECHANGE Mode as capture rate very high.
    Please capture one transaction details of write and read.

    Best Regards,
    Sudheer

  • It is very difficult to decode the waveform shared during STATECHANGE Mode as capture rate very h

    Hi,
    I am not able to get one transaction in statechange mode. I get infinite number of read transactions for PHY address starting from 0 to n number. On initializing the MDIO in satechange mode, I cannot capture just one transaction.
    Please share the configuration of MDIO in statechange mode. Currently in my case I am configuring the 

    CLKDIV (bit 0-15),  ENABLE (bit 30), PREAMBLE (bit 20) of control register. and enable the 30th bit of CPSW_MDIO_POLL_REG

    Regards
    Manisha N G
  • Hi,

    Hi,
    I am not able to get one transaction in statechange mode. I get infinite number of read transactions for PHY address starting from 0 to n number. On initializing the MDIO in satechange mode, I cannot capture just one transaction.

    In your capture, Stop the capture from Oscilloscope.
    Change the time window i.e. adjust the frequency so that you can view one Write transaction.

    CLKDIV (bit 0-15),  ENABLE (bit 30), PREAMBLE (bit 20) of control register. and enable the 30th bit of CPSW_MDIO_POLL_REG

    If your PHY Support disabling/ignore of preamble then only you should set PREABLE (bit 20). If not you should not set it.
    Above will be sufficient for enabling STATECHANGE Mode.

    Have you tried writing BMCR with specific value and read back to check whether written and read are same or not?

    Best Regards,
    Sudheer

  • Have you tried writing BMCR with specific value and read back to check whether written and read are same or not?

    Hi,
    I tried doing it. The value read from BMCR is always 0.

    If your PHY Support disabling/ignore of preamble then only you should set PREABLE (bit 20). If not you should not set it.
    Above will be sufficient for enabling STATECHANGE Mode.

    PEAMBLE (bit 20) is set to 0 only. I cannot stop the Oscilloscope to capture because once I execute the MDIO initialization function, I see the Oscilloscope as shown  below

    I cannot afford time to learn in STATECHANGE mode again. I always tested the MDIO manual mode by writing to BMCR register and tried to read the value from the same register. It is always read 0.

    I read the value of the register 0x2 (BMSR). I read the value 0x2000. I guess read function in manual mode works fine. I am not sure why writing is not possible?


    Kind Regards
    Thank You
    Manisha N G

  • Hi,

    I cannot afford time to learn in STATECHANGE mode again. I always tested the MDIO manual mode by writing to BMCR register and tried to read the value from the same register. It is always read 0.

    I read the value of the register 0x2 (BMSR). I read the value 0x2000. I guess read function in manual mode works fine. I am not sure why writing is not possible?

    It seems Read is working as expected.
    But, in previous waveforms read is non-zero , how come read is Zero now? Have you made any changes to APIs?

    You can write any of R/W write register and read back the same register after writing and check whether same is read or not.

    Best Regards,
    Sudheer

  • It seems Read is working as expected.
    But, in previous waveforms read is non-zero , how come read is Zero now? Have you made any changes to APIs?

    Read of BMCR is always zero for the first time. 2nd time if i read the same register it is non zero but not the value what I write to BMCR register,

    You can write any of R/W write register and read back the same register after writing and check whether same is read or not.

    I am trying to do this from the start.
    I cannot understand how else to evaluate my write function.

    Regards
    Manisha N G

  • Hi,

    It seems Read is working as expected.
    But, in previous waveforms read is non-zero , how come read is Zero now? Have you made any changes to APIs?

    Read of BMCR is always zero for the first time. 2nd time if i read the same register it is non zero but not the value what I write to BMCR register,

    Is it same in case STATE CHANGE Mode.
    Have you checked any reserved fields in BMCR, which might not take affect of value written.

    Have you modified the Read sequence from TI reference or is it same as TI Reference?

    You can write any of R/W write register and read back the same register after writing and check whether same is read or not.

    I am trying to do this from the start.
    I cannot understand how else to evaluate my write function.

    There is no other way, you have to write and then read back.

    Best Regards,
    Sudheer

  • Have you checked any reserved fields in BMCR, which might not take affect of value written.

    There are bits from 0-5 they are reserved and 6th bit is read only. I take these points in consideration while writing the data to PHY registers.

    Is it same in case STATE CHANGE Mode.

    I mentioned the issue I am facing in STATECHANGE mode.

    Now I noticed one that that there is raise of DATA line for 2.65 us on writing the register address. My instructions follows the same sequence in TI pdk. Please take look at the below picture.

    This is not seen in write function. Also can you please send me waveform of correctly executable read function.

    Kind regards
    Manisha N G

  • Hi,

    Is it same in case STATE CHANGE Mode.

    I mentioned the issue I am facing in STATECHANGE mode.

    In case of STATECHANGE Mode you should not observe any Issue, as MDIO transaction handled by H/W.
    If your PHY is not responding in STATECHANGE Mode, then it could be your PHY issue. Please check with PHY Vendor.

    This is not seen in write function. Also can you please send me waveform of correctly executable read function.

    Above you said, read is working fine. But why you want Read sequence.

    For MDIO Errata, Please refer to PDK/MCAL based MDIO Manual Mode implementation from TI SDKs. Which is working fine on TI EVM and many customers also using the same with different PHYs.

    Best Regards,
    Sudheer

  • Hi ,
    Thanks for your answer. I have one last question about CpswMdio_manualPhyRegRead22 function. After sending all the commands to rad the PHY and setting MDIO_OE bit to 0,clock is toggled followed by, PHY acknowledgement and Clock is toggled. I understand the 1st toggling is because of the turn around time before reading the PHY register, but why there is clock toggling after reading the PHY acknowledgement?

    Kind Regards
    Manisha N G

  • Hi,

    After sending all the commands to rad the PHY and setting MDIO_OE bit to 0,clock is toggled followed by, PHY acknowledgement and Clock is toggled. I understand the 1st toggling is because of the turn around time before reading the PHY register, but why there is clock toggling after reading the PHY acknowledgement?

    Turn around is 2 bits.
    First time MAC will keep the MDIO High, and toggle the clock. and then wait for MDIO toggle by PHY in next clock.
    The data transfer will start after next clock of ACK.

    Best Regards,
    Sudheer