DP83867CR: Link status bit and LED_0 ON even though cable not connected

Some more information:

register 0x0031 was 0x10b1 so I wrote 0 to it

It didn't help.

What is strange when I read it back it is 0 but there are some reserved bits that are '1' and RO and they are also '0' now.

Why does the PHY wake up in Internal Test Mode (address 0x31 bit 7 starts up as '1' instead of '0')?

After additional attempts at seeting normal opertational mode (instead of Internal Test Mode) we have successfully achieved acurate link status when connecting/dicsonnecting LAN cable.

In addition we have successfully transmitted from CPU(MAC) to external PC.

We still have 1 open issue - Recieving data from PC to CPU(MAC) - no success yet.

Hi Dan, 

Dan Kessler said:

Are the recieve and transmit clocks on the CLK_OUT pin derived from the RX_CLK and TX_CLK of the MAC interface? or are they internally generated?

When there is a link, these are recovered clock from the MDI line. In this case in which the link is up but there is no actual connection, the PHY may not be sending out the correct clock frequency. 

Based on your information, it seems like the internal test mode is causing the link to be up even when there is no cable connected. 
In addition, it looks like your TX MAC -> PHY -> MDI -> PC works. 
Since the receiving doesn't work, I suspect it could be a timing issue on the RGMII side. Have you tried using delay mode in the PHY and then change the delay of the RX_CLK on the PHY?
This can be done by accessing registers 0x32 and 0x86. 

In addition, if you read 0x15, do you see any rx_err_cnt going up?

Best,
J

Why does the PHY wake up in Internal Test Mode?

I tried configuration as in schematics (Mode 3) and also tried removing R301 and changed R300 to 2.49Kohm (Mode 4).

In both cases the PHY starts up in "Internal Test Mode" - No cable connected. Also why is port mirroring enabled.

In both cases register 0x0031=10B1, 0x006E=0x88A0

below is scope recording of voltage for Mode 4 - Yellow RX_CTRL pin, Cyan/Blue is the 3.3v (VDDIO)

As you can see the voltage is 2.6v which is as it should be 0.783*3.3=2.58v

Hi Dan, 

This is very weird. So, to confirm, the PHY ALWAYS ramps up into internal test mode?
If this is not the case, could you send me the register content of 0x6E and 0x6F when the PHY initializes in the good state?
Are there any other strapping that is done to the PHY, or does the MAC drive any of these lines at the power up of the PHY?

Lastly, when the PHY enters internal test mode, could you see if resetting the device (0x1F=0x8000) or pulling the reset pin low fixes the issue?

Best,
J

Yes the PHY always ramps up into Internal Test Mode.

The only strapping I have is the RX_CTRL, LEDs, GPIOs - all described in schematics in OP.
In RGZ (48pin QFN) only RX_D0 and RX_D2 are relevant in the CPU MAC interface but they seem to be OK because the PHY ADDR we get is 00000 as expected.

When we reset via the 0x001f register (0x8000 and 0x4000) the results are the same - still Internal Test Mode.

What are the conditions of the PHY to enter this mode?

The physical reset is also connected to the CPU (pressing it doesn't solve the problem). I can Isolate the PHY from this reset but need to do some wire-ups (remove series ressitor). Will try...

I did an additional measurement for the RX_CTRL pin strapping for original design (Mode 3) and the results are as expected.
Accoring to datasheet for Mode 3 the voltage should be (for VDDIO=3.3v) between voltage 0.7425v and 0.9372v. We get 0.82v which is OK

So still no explanation why the PHY is ramping into Internal Test Mode

I did several resets (using reset button on my board and always the same results)

Below is the scope readings - Yelllow is RX_CTRL, Cyan is RESET_N pin

And zooming in on the RESET_N release time period

Additionally, I also saw in datasheet 

I checked 0x006F = 0x0170 so bit 8 is '1' and not '0' so does that mean the request was not from RX_CTRL strapping? and if so then from where?

Hi Dan, 

Strapping is typically sampled 120ns after reset goes high. 
Looking at the scope shot, it looks like RX_CTRL is low around 120ns mark so this seems to be why it is being mis-strapped.

My first guess is that the MAC/level shifter is somehow driving this line and cause this. If you isolate the RX_CTRL connection, does the PHY still enter the test mode?

Best,
J

I don't know how to isolate the signal but will try.

But according to the datasheet and what I wrote above the RX_CTRL strapping is not the issue (register 0xf6[8] is not '0'.
I will try and strap RX_CTRL to mode 0 or mode 1 and see if the bit changes to '0' to make sure the INTERNAL TEST MODE indication is as described in the datasheet.

So I changed the RX_CTRL to Mode 1 (OPEN, OPEN) is shown in datasheet (removed R300 and R301)

And the scope showed as expected voltage of under 10mV (before and after reset so doesn't matter where it is actually latched) which as indicated above is consistent with mode 1. 

Register 0x31 = 10B1 (as usual) - Internal Test Mode as exprected but now also register 0x6F = 0x0070 is as expected - Bit 8 is now '0' meaning RX_CTRL strapping is not valid (Mode 1/2 and not 3/4).

Meaning previously in Mode 3/4 when 0x6F = 0x0170 (Bit 8 was '1') the RX_CTRL strapping was OK - recognized as mode 3/4.

Then why is the PHY ramping into Internal Test Mode?

Also suspected LED_0 strapping so removed physical LED so LED_0 is left floating - strapping entered mode 1 (no mirroring) as expected (only modes 1 and 3 are valid) and still 0x0031 bit 7 is '1' - Internal Test Mode

Hi Dan, 

How were you able to recover the PHY into a normal operation mode initially when this happened? We are checking internally to see how the test mode is being enabled.

Best,
J

This is the way we recover from Internal Test Mode - given to me by SW team:

After loading U-Boot, auto-negotiation failed, we began debugging by checking the default values of the PHY registers and found the following issues:

• Configuration Register 4 (CFG4) at address 0x0031 was not in its default state, internal test mode and port mirror were enabled.
• BIST Control Register (BISCR) at address 0x0016 was also not at its default value, the value was 0x3, PCS loopback was enabled, the register value was 0x3, and the speed was set to 1000 Mbps.

After manually resetting the PHY using register 0x001f=0x8000 and clearing each register (0x0031 and 0x0016) after loading the driver in the Linux kernel, we achieved a stable connection.

In the kernel, I set registers 0x0031 & 0x0016 to 0 in the configuration handler.

However, after auto-negotiation completed, the BISCR register changed to a value of 0x3, to resolve this, I cleared the register again after auto-negotiation done.

 The auto-negotiation-done handler is triggered whenever the link status changes, so I cleared the registers each time the handler was called.

I cleared register 0x0031 in the configuration handler, and since register 0x0016 changed after auto-negotiation, I cleared it each time the handler was invoked in the driver.

Hi Dan, 

It is weird that PCS loopback gets automatically enabled. This is an unexpected behavior and cannot happen unless the driver writes to that register. I also verified in the lab that if PCS loopback is on, the link status will go high (0x0016 = 0x0001) and link status does not go high from the internal test mode. So, PCS loopback somehow being enabled is most likely your issue, not the internal test mode. The PHY should function normally even with the test mode enabled. 

Could you check in with the SW team to see if the driver writes to register 0x0016 at the initial boot up? It seems like Linux is writing to BISCR register every time auto-negotiation status changes. 

Please let me know. 

Best,
J

I will check with SW team. But even loading uboot (before linux) we already see the register 0x0016 = 0x0003.

Hi Dan, 

Please keep me updated on the SW side. If this is a strapping issue, after doing a software reset (0x001F = 0x8000), the PHY should still be in PCS loopback (0x0016 = 0x0003). Could you see if the PHY is still in this state if you do a software reset but do not write any values to 0x0031 and 0x0016?

Best,
J

When doing a SW reset the PCS loopback changes from 0x3 to 0x0.

Internal Test Mode is still '1' - Doesn't change.

Hi Dan, 

Because the SW reset properly resets register 0x0016 to 0x0000, I am suspecting that this register is not being triggered from the hardware strapping. Therefore, I suspect that the SW is somehow writing 0x3 to the 0x0016 register. 

Internal test mode being enabled will not have any impact on the functionality of the PHY. We are looking more into this internally to see why this bit is being enabled despite RX_CTRL pin is strapped to mode 3 and 4. 

We will keep you updated. 

Best,
J

Hi,

We identified that the issue with register 0x0016 was due to the software writing 0x3 to it and this has now been resolved.

However, we are still experiencing a problem with register 0x0031, after resetting the PHY—either by writing 0x8000 to register 0x1f or performing a normal board reset, we observe a value of 0x10B1 in register 0x0031.
In the Linux kernel, we clear this register in the driver within the dp83867_config_init function, Additionally, before initializing the PHY, we write 0x1012 to register 0x0010, and after this step, the PHY operates as expected in the kernel.
We followed the same procedure in U-Boot, but it did not work (no ping or ARP messages!), Could you please explain why this might be happening?

We are using U-Boot 2016.11 fslc , maybe we should use the latest?

Regards,

Wesam

Hi Wesam,

As I said in the previous post, the internal test mode should not have any impact on the PHY's functionality, but we are verifying internally to see why this is being enabled in the mode 3/4 of the RX_CTRL strap. We will keep you updated. 

wesam hazbon said:

Additionally, before initializing the PHY, we write 0x1012 to register 0x0010, and after this step, the PHY operates as expected in the kernel.

When you say the PHY operates as expected in the kernel, does this mean the PHY can ping and do ARP messages?

I looked at register 0x0010 and it looks like 0x1012 disables 125MHz clock and enables line driver inversion:


Disabling 125MHz clock and inverting line driver will impact the PHY functionality as it does not seem like MDI lines are not reversed in the schematic and RGMII needs 125MHz clock. 

Best,
J

Hi,

Hi Wesam,

US office is closed for holiday 9/1. I will get back to you on 9/2 US time.

Best,

J

Hi Wesam, 

The default value on register 0x0010 is 0x5048. Bit 11 is reserved and altering this bit will cause issues with the PHY functionality. When this issue happens, could you check if the voltage of the LED_0 pin is at mode 0 and not at different mode? 

Best,
J

Regarding LED_0 I tried with DS28 physically installed and also diconnected (removed).

With the LED the reset value was 0x5848 after writing 0x8000 to register 0x1f and port mirroring was "Enable port mirroring" bit (0) of register 0x31 was '1' (0x10B1)

Without the LED the reset value was 0x5048 after writing 0x8000 to register 0x1f and port mirroring was "Normal operation" bit (0) of register 0x31 was '0' (0x10B0)

When initiating a HW reset using reset button the voltages were:

Without the LED ==> 0v (<20mV):

With the LED ==> 1.6v/3.3v:

Zoom on reset release

Hi Dan, 

The reserved bit (bit 11 of 0x0010) is affected by the strapping of LED_0 pin. Because LED_0 pin is 1.6V, this is causing the LED_0 pin to strap to mode 4. Thus, this enables the reserved bit to go high. We have a note in the datasheet to strap LED_0 pin in mode 1 or 3:

Please ensure that LED_0 pin is around 0.255 x VDDIO which would be around 0.84V. 


Previously, customers have used the configuration below to achieve this:



Best,
J

Hi,

After removing the LED, the value of register 0x10 is 0x5048. In the Linux, clearing register 0x31 resolves the issue and everything works, but we still have problems in UBoot no ping and no ARP. Do you have any suggestions for fixing this? We are using U-Boot fslc 2016, Should we consider updating to the latest version?

Regards, Wesam

Hi Wesam, 

Could you dump the register info from 0x00 to 0x1F? I wonder if there are any register that gets changed from uboot to linux kernel. 
What is the exact error you see on ping and ARP also?
Have you verified that 0x0011 and 0x0016 values are consistent with the values on the linux kernel?

Best,
J

Hi,

There are no specific error, both ping and ARP are non functional.

The basic network connectivity is not working on uboot.

Here are the registers where the U-Boot value is different from the Linux value:

Registers from 0 to 0x1f

  Thanks

Hi Wesam, 

I noticed that uboot advertises both half and full duplex while Linux only advertises half duplex. Could there be a duplex mismatch possibly causing the link to be up, but no data is being transmitted?

Also, could you share a screenshot what you mean by non functional? It's quite hard to imagine what you mean by non-functional without any error so. 

Please let me know. 

Best,
J

Linux:

Uboot:

Hi Wesam, 

Thank you for your screenshot. 
This could be a dumb question, but is the MAC address set? It seems like you only set IP address in the screenshot you sent. Also, I checked the similar uboot screenshot that Dan posted and it looks like MAC address is never set:


Please let me know.

Best,
J

Yes, the MAC is set, it is a mechanism that reads the MAC address from an EEPROM.

If the EEPROM is empty, a default MAC address will be used.

If the MAC address is not set, you should see "ethaddr is not set" immediately after executing the ping command.

The same code and U-Boot version work with the old PHY, also the same MAC address is used in the kernel.