Other Parts Discussed in Thread: DP83869
Tool/software:
Hello,
We are experiencing difficulties in testing the Ethernet physical layer DP83869HMRGZT since we are not able to address it with FPGA. On our PCB we are using DP83869 in RGMII configuration with a System-on-Module (KRIA K26, integrating Zynq® UltraScale+
MPSoC). In the attached file you can find schematic pages related to Ethernet Phy.
Regarding firmware and software, we are trying to read the IEEE_CONTROL_REG_OFFSET (=0x0) using the value 0x0 as phy_addr. The HW used is the Ethernet PS (GEM1) at address 0xff0c0000 of UltraScale+ Manual, as made in Kria KR26 Robotics Kit. The clock is visible (we also tested with scope), but the Phy is not responding and the read value is 0xFFFF. Thus, we cannot read the phy_identity of the chip. Before running this command, we also reset the phy with this sequence: HIGH, wait 500ms, LOW, wait 500 ms, HIGH. We also measured RBIAS voltage and got 0V instead of 1V.
Here is our used code for FPGA:
/**
* Read the current value of the PHY register indicated by the PhyAddress and
* the RegisterNum parameters. The MAC provides the driver with the ability to
* talk to a PHY that adheres to the Media Independent Interface (MII) as
* defined in the IEEE 802.3 standard.
*
* Prior to PHY access with this function, the user should have setup the MDIO
* clock with XEmacPs_SetMdioDivisor().
*
* @param InstancePtr is a pointer to the XEmacPs instance to be worked on.
* @param PhyAddress is the address of the PHY to be read (supports multiple
* PHYs)
* @param RegisterNum is the register number, 0-31, of the specific PHY register
* to read
* @param PhyDataPtr is an output parameter, and points to a 16-bit buffer into
* which the current value of the register will be copied.
*
* @return
*
* - XST_SUCCESS if the PHY was read from successfully
* - XST_EMAC_MII_BUSY if there is another PHY operation in progress
*
* @note
*
* This function is not thread-safe. The user must provide mutually exclusive
* access to this function if there are to be multiple threads that can call it.
*
* There is the possibility that this function will not return if the hardware
* is broken (i.e., it never sets the status bit indicating that the read is
* done). If this is of concern to the user, the user should provide a mechanism
* suitable to their needs for recovery.
*
* For the duration of this function, all host interface reads and writes are
* blocked to the current XEmacPs instance.
*
******************************************************************************/
LONG XEmacPs_PhyRead(XEmacPs *InstancePtr, u32 PhyAddress,
u32 RegisterNum, u16 *PhyDataPtr)
{
u32 Mgtcr;
volatile u32 Ipisr;
u32 IpReadTemp;
LONG Status;
Xil_AssertNonvoid(InstancePtr != NULL);
/* Make sure no other PHY operation is currently in progress */
if ((!(XEmacPs_ReadReg(InstancePtr->Config.BaseAddress,
XEMACPS_NWSR_OFFSET) &
XEMACPS_NWSR_MDIOIDLE_MASK))==TRUE) {
Status = (LONG)(XST_EMAC_MII_BUSY);
} else {
/* Construct Mgtcr mask for the operation */
Mgtcr = XEMACPS_PHYMNTNC_OP_MASK | XEMACPS_PHYMNTNC_OP_R_MASK |
(PhyAddress << XEMACPS_PHYMNTNC_PHAD_SHFT_MSK) |
(RegisterNum << XEMACPS_PHYMNTNC_PREG_SHFT_MSK);
/* Write Mgtcr and wait for completion */
XEmacPs_WriteReg(InstancePtr->Config.BaseAddress,
XEMACPS_PHYMNTNC_OFFSET, Mgtcr);
do {
Ipisr = XEmacPs_ReadReg(InstancePtr->Config.BaseAddress,
XEMACPS_NWSR_OFFSET);
IpReadTemp = Ipisr;
} while ((IpReadTemp & XEMACPS_NWSR_MDIOIDLE_MASK) == 0x00000000U);
/* Read data */
*PhyDataPtr = (u16)XEmacPs_ReadReg(InstancePtr->Config.BaseAddress,
XEMACPS_PHYMNTNC_OFFSET);
Status = (LONG)(XST_SUCCESS);
}
return Status;
}
I hope you can give us some hint or information to solve this issue or tell us if there anything we can improve in our design.
Thank you for your help.
