DP83848K: Link problem

Hi Takumi-san,

To understand your problem better, 
You have the following system:

10M 83848K <==== copper ====> 100M 83848K

Is this correct?
If so, is it okay to assume that the behavior below was seen from 10M 83848K? 

Takumi Suzuki1 said:

When they checked the PHYIC output and input signal waveforms, the following was confirmed.

・The TD (+/-) pins output a 10Mbps First Link Pulse (FLP) waveform (as they set)

・The RD (+/-) pins input a 100Mbps waveform from the other side

Takumi Suzuki1 said:

Check link status: See 0 bit of PHYSTS 0x10h

Do you mean they see 0x0000 on PHYSTS? If so, this means link is not established so the link is down. 


Also, if the below is for 10M 83848K, what is the BMCR register setting for 100M 83848K? 

Takumi Suzuki1 said:

Settings for 10M full-duplex: Set x"0100" to BMCR 0x00h

Settings for 10M half-duplex: Set x"0000" to BMCR 0x00h

Do you happen to have a schematic of this system so we can understand what your strap configurations are, if they use any strap configurations?

Please let me know. 

Best, 
J

Hi J-san,

Thank you for your reply.

Let me answer your questions as below.

>10M 83848K <==== copper ====> 100M 83848K

>Is this correct?   

  Yes, correct.

>If so, is it okay to assume that the behavior below was seen from 10M 83848K? 

 Yes, correct.

"10M 83848K" outputs 10MHz signal and receives 100MHz signal from the other side.

Under this condition, Link down behavior has not happened... 

Since the communication modes on the PHYIC side and the opposite side are different, the customer expects a "Link-down" behavior.

>Do you mean they see 0x0000 on PHYSTS? If so, this means link is not established so the link is down. 

No, they see/check the "Bit0 Link status" of PHYSTS.

As of now, I do not have the schematic and I will try to get it.

Can I understand that this issue seems to be related not only register settings but also device pin settings? 

Again, I would appreciate your advice on what settings could be causing this issue and what measures can be taken.

If the register settings are incorrect, please let me know the correct settings.

Thank you for your support & Regards,

Takumi

Hi J-san,

Will you tell me your e-mail adress?

Let me send you the schematic if I can get.

Thanks and Regards,

Takumi

Hi Takumi-san,

My email address is jbyoon@ti.com

Takumi Suzuki1 said:

Can I understand that this issue seems to be related not only register settings but also device pin settings? 

Yes, knowing the device pin settings will be helpful in evaluating the issue. 

Could they also send the BMCR and ANAR register setting for "100M DP83848K"?
I am wondering if auto-negotiation is enabled on 100M DP83848K and is advertising 10M.

Please let me know.

Best,
J

Hi J-san,

Thank you for your reply.

I am asking the customer to give us the schematic.

Please wait a moment.

And about "100M side", the device may not be DP83848K..I am checking the customer about it.

Thanks and Regards,

Takumi

Hi Takumi-san,

I will wait for your update. 

Best,
J

Hi J-san,

Thank you for waiting.

I have sent the documents to your mail adress.

Please check them and support this issue.

Thanks!

Takumi

Hi Takumi-san, 

I received your email. 

I reviewed the schematic and the register settings.

It looks like the customer's auto-negotiation advertisement is set to 100M half/full duplex. 
According to the schematic, the auto-negotiation pins are set to AN0 = 1 and AN0 = 0 which advertises 100M half/full duplex mode. 
I confirmed this with ANAR register (0x0004) bit 7 and 8 being 1. 
I also confirmed that 10Base-Tx bits in the ANAR register is 0; hence those advertisements are off. 

To change the advertisement, you can toggle them after the PHY powers up, or change the pin strap to AN0 = 0 and AN0 = 0. So, for both pins, they would be pulled down to GND at the PHY power-up. 

Please let me know how this goes. 

Best, 
J

Hi J-san.

Thanks for your reply!

Let me confirm the following explanation.

As I understand it,

1) The observed phenomenon is caused by pin settings and register settings, both settings were "100M half/full duplex mode".

2) To solve this issue, both settings should be 10M mode.

That is, you should set pin AN0=0, AN1=0, ANAR register bits 6 and 7 should be set to 1, and bits 7 and 8 should be set to 0.

Is this correct?

I have one more question.

How will DP83848K behave if the pin settings and ANAR register settings are different?

For example, if ANAR is set to 10M and the pin settings are 100M.

Thanks for your help.

Best regards.

Takumi

Hi Takumi-san, 

Takumi Suzuki1 said:

2) To solve this issue, both settings should be 10M mode.

That is, you should set pin AN0=0, AN1=0, ANAR register bits 6 and 7 should be set to 1, and bits 7 and 8 should be set to 0.

Is this correct?

Your understanding is correct.

Takumi Suzuki1 said:

How will DP83848K behave if the pin settings and ANAR register settings are different?

So, it is okay to change ANAR register settings after the device powers on. However, I noticed that the customer's board had option to change the pin strap setting to force the device into 10M mode so I would recommend the customer to populate such resistor. Then, the customer wouldn't have to change the resistor setting every time the device powers on. 

The pin setting is as such:


To set 0 on pin strap, the customer needs to connect AN0 to GND with pull-down resistor of 2.2k. 

Please let me know if you have any questions. 

Best,
J

Hi Takumi-san,

Please let me know if there's any update. 

Best,
J

Hi J-san,

Thank you for waiting.

I have received confirmation results from the customer as below.

■TI response configuration
Pin settings: AN0=0, AN1=0
ANAR register settings: Bit5/6=1, Bit7/8=0 (x"0061")
Concentrator: 10M full duplex or 10M half duplex
Measuring device side: 100M full duplex or 100M half duplex
The problem was not improved.

--------------------------------------------------------
We also confirmed the following additional configuration.

■Configuration①
Pin settings: AN0=0, AN1=1
ANAR register settings: Bit6/8=1, Bit5/7=0 (x"0091")
Concentrator: 10M full duplex or 10M half duplex
Measuring device side: 100M full duplex or 100M half duplex
The problem was not improved.

■Configuration ②
Pin settings: AN0=1, AN1=1
ANAR register settings: Bit5/6/7/8=1 (x"01E1")
Concentrator: 10M full duplex or 10M half duplex
Measuring device side: 100M full duplex or 100M half duplex

The problem was not improved.
---------------------------------------------------------

In the three results above,
the problem of linking up was not improved.
Does this mean that there are other items that have not yet been taken care of?

Will you tell me your idea about this?

Best Regards,

Takumi

Hi Takumi-san, 

Thank you for the update. I appreciate doing the additional configurations also. 

I reviewed the register map again and I noticed that the register 0x00 is set to 0x0000 or 0x0100. This means that the PHY was forced to be on 10M half/full duplex mode this entire time so auto-negotiation was turned off. 

Therefore, I am wondering if the customer setting on the Ethernet module is correct. If possible, could they gather register information of 0x00 to 0x1F on the ethernet module?

Also, could the customer check if the link is happening on other link partners, if this is possible? Connecting to another 848 PHY with 10M forced or 100M forced mode will verify that the PHY is not the issue here. 

Lastly, could you ask if the customer is putting the PHY into power cycle each time they test the link? I am wondering if the PHY settings are overwritten when they power cycle since 848K does not have a pin-strap setting to disable auto-negotiation. 

Please let me know. 

Best,
J

Hi J-san,

Thank you for your reply.

Let me ask you as below to understand your answer well.

Q1)  " I noticed that the register 0x00 is set to 0x0000 or 0x0100.

        This means that the PHY was forced to be on 10M half/full duplex mode this entire time so auto-negotiation was turned off. "

         --->  Do you meand that the customer must set "1" to Bit12 of BMCR(0x00) register, correct?

Q2)  "If possible, could they gather register information of 0x00 to 0x1F on the ethernet module?"

         ---> About the register setting of the customer, there described the documents I sent the other day... 

               What do you mean "ethernet module"? Anritsu MP1590B?? If yes, I suppose it seems to be difficult to get the value..

Q3) "Also, could the customer check if the link is happening on other link partners, if this is possible?"

        ---> Sorry I do not understand well, do you mean to ask the customer to try to conect another equipment?

               Now the partner is "Anritsu MP1590B". Do you recomend to try to connect another equipment but Anritsu? 

Q4) "Lastly, could you ask if the customer is putting the PHY into power cycle each time they test the link?"

       ---> Will you tell me the meaning of "power cycle"? Does this mean "power ON and power off", correct?

Sorry for my poor understanding.

Thank you for your kind support.

Best Regards,

Takumi

Hi Takumi-san,

Takumi Suzuki1 said:

Q1)  " I noticed that the register 0x00 is set to 0x0000 or 0x0100.

        This means that the PHY was forced to be on 10M half/full duplex mode this entire time so auto-negotiation was turned off. "

         --->  Do you meand that the customer must set "1" to Bit12 of BMCR(0x00) register, correct?

No, not necessarily. Because Bit 12 of BMCR is 0 currently, this means that PHY cannot make link with devices in 100M based on their current setting of bit 8 and 13 of the BMCR. Therefore, I started suspecting the Anritsu is trying to connect on 10M. 

If the customer wishes to use auto-negotiation feature, they should set bit 12 to 1. 

Takumi Suzuki1 said:

Q2)  "If possible, could they gather register information of 0x00 to 0x1F on the ethernet module?"

         ---> About the register setting of the customer, there described the documents I sent the other day... 

               What do you mean "ethernet module"? Anritsu MP1590B?? If yes, I suppose it seems to be difficult to get the value..

Yes, I mean Anritsu MP1590B. 

Takumi Suzuki1 said:

Q3) "Also, could the customer check if the link is happening on other link partners, if this is possible?"

        ---> Sorry I do not understand well, do you mean to ask the customer to try to conect another equipment?

               Now the partner is "Anritsu MP1590B". Do you recomend to try to connect another equipment but Anritsu? 

Yes, I recommend trying another equipment if possible. If not, try connecting to another 83848K board if there is an extra board. 

Takumi Suzuki1 said:

Q4) "Lastly, could you ask if the customer is putting the PHY into power cycle each time they test the link?"

       ---> Will you tell me the meaning of "power cycle"? Does this mean "power ON and power off", correct?

Yes, I mean completely powering on and off the device. So, do they cut off the electrical supply every time they test the PHY, or do they just do a soft reset?

Best,
J

Hi J-san,

Thank you for your answer !

Let me ask you your questions to the customer.

Please wait a moment.

Best Regards,

Takumi

Hi Takumi-san,

Please keep me posted.

Best,

J

Hi Jsan,

Thank you for your support.

I have got the following feedback from the customer.

Will you confirm the contents?

About the image data, let me send you later.

******

A1)  We have confirmed that the Anritsu MP1590B outputs 100BASE-TX pulses.

  Please check the attached "Image_10M_FLP_100M".

  (Confirmed with DP83848 RD+ (12pin) and RD- (11pin))

  And please check the attached "Image_Anritsu Settings".

A2)  We confirmed with the following devices. .

 -Allied Telesis Switch HUB GS908S-TP V2

 -Allied Telesis Switch HUB FS708XL

Concentrator set to 10M on both devices. Switch HUB set to 100M Link-up was confirmed. (About 3 times out of 10 insertions and removals)

*If link-up occurs, the issue is resolved by unplugging the cable and link-down.

A3) The power is turned on and off every time the PHY is tested.
Power ON → Release hard reset pin (RESET_N(23pin)) → Write to register

*The write sequence is BMCR(0x00) → PHYCR(0x19) → ANAR(0x04).

Also, no soft reset is performed.

There is no control over the 15th bit of BMCR(0x00) "Reset".

*****

I appreciate your kind support very much.

Best Regards,

Takumi

Hi Takumi-san,

Could you ask the customer to turn ON the auto-negotiation for both Anritsu device and the 83848K PHY and advertise both 10/100M? 
We would like to see if the PHY and the Anritsu device both link up properly. 

Please let the customer know to enable auto-negotiation by writing 0x1000 to BMCR (0x00) register.

I know the customer has done additional configurations with AN0 and AN1 strapping options, but these options are ignored when the customer writes 0x0100 to BMCR which turns auto-negotiation off. 

Please let me know. 

Best,
J

Hi J-san,

Thank you for your reply!

Let me understand your instraction as below.

You would like to check whether they link up correctly by turning on auto-negotiation on both devices.
My understanding is that you should check that they link up even if Anritsu outputs 100M.

That is, you would like to confirm in case either 10M or 100M is out from Anrits, the link is always link up properly.

Is my understanding correct?

Do you have any advice for customers after that?
What should they do if they link up correctly?
And what should they do if they don't link up?

Thank you for your support.

Best Regards,

Takumi

Hi Takumi-san,

Takumi Suzuki1 said:

That is, you would like to confirm in case either 10M or 100M is out from Anrits, the link is always link up properly.

Is my understanding correct?

Yes, please confirm if it can work with auto-negotiation is enabled on both side. Please advise them to try all cases: advertise only 10M, or 100M, and advertise both 10 and 100M on both devices and if they link up properly to the fastest speed in all cases. 

Takumi Suzuki1 said:

Do you have any advice for customers after that?
What should they do if they link up correctly?
And what should they do if they don't link up?

We will have additional instructions after we confirm this. 

Thank you for your patience.

Please let me know how this goes.

Best,

J

Hi J-san,

Thanks for your reply！

I understood.

I will ask the customer to try.

Thank you and Best Regards,

Takumi

Hi Takumi-san, 

Please let me know!

Best,
J

Hi J-san,

Thank you for waiting.

I got the answer from the customer as below.

*****

When both the concentrator and the Anritsu device were connected with Auto Negotiation ON, the link-up was successful.

*x"1000" was written to the BMCR register.

*****

Will you consider about this?

I will wait for your next instruction.

Thanks and Regards,

Takumi

Hi Takumi, J is out of office until next week, so I will support this in the meantime.

It sounds like auto negotiation works, however you get a link up occasionally when forcing 10M on the 848K and connecting to a 100M link partner.

This behavior is unexpected as a link should not be established between a 10M PHY and 100M PHY. I can look into this, however I'd like to communicate that DP83848K is an older device and does not receive much design support.

Does the customer have the option to switch to a newer PHY in our DP8382x family? I have not heard of this issue in our newer PHYs so would like to propose DP83826 as an alternative.

Best,

Shane

Hi Shane-san,

Thank you for your reply !

Let me understand the contents of your reply as below.

My following understanding is correct?

 - This phenomenon (links occasionally being established between 10M PHY and 100M PHY) may be a potential defect in the DP83848K.

 - As this device is old (released in 2008), so it is difficult to investigate the cause.

 - The designer from that time is no longer with us, so even if we investigate, the cause may not be found.

 - We propose the DP83826 as an alternative to the DP83848K. (This phenomenon has not been reported with the DP83826.)

   The DP83826 can be considered an updated version of the DP83848K. (It's a bit difficult to say, but we understand it as a defect fix version...)

Q1) This phenomenon of DP83848K has been reported by other customers, correct?

Q2) The DP83826 has 2 types(I and E versions), but what is the difference? (Temperature range?)

I appreciate your kind support.

Best Regards,

Takumi

Hi Shane-san,

Sorry let me ask you one more question.

Q3) Is there any solution to prevent occurring from this phenomenon?

      We should prepare external additional circuits to use DP83848K??

Again thank you for your support.

Best Regards,

Takumi

Hi Takumi-san,

Takumi Suzuki1 said:

This phenomenon (links occasionally being established between 10M PHY and 100M PHY) may be a potential defect in the DP83848K.

Would need to reproduce this behavior on a known-good EVM to confirm. We do not have this in our lab and would need to order one to investigate.

Takumi Suzuki1 said:

As this device is old (released in 2008), so it is difficult to investigate the cause.

Correct

Takumi Suzuki1 said:

The designer from that time is no longer with us, so even if we investigate, the cause may not be found.

Correct

Takumi Suzuki1 said:

We propose the DP83826 as an alternative to the DP83848K. (This phenomenon has not been reported with the DP83826.)

Correct

Takumi Suzuki1 said:

 The DP83826 can be considered an updated version of the DP83848K. (It's a bit difficult to say, but we understand it as a defect fix version...)

That is one way to put it. The DP83826 is a new device with similar functionality (MII/RMII to copper MDI).

Takumi Suzuki1 said:

Q1) This phenomenon of DP83848K has been reported by other customers, correct?

I see there was a similar question in the past, however it is not the same as what you're testing. I'm not aware of this issue being reported by other customers.

Takumi Suzuki1 said:

Q2) The DP83826 has 2 types(I and E versions), but what is the difference? (Temperature range?)

Correct, the difference is in the temperature range (shown here in the datasheet)

Takumi Suzuki1 said:

Q3) Is there any solution to prevent occurring from this phenomenon?

If the link has one PHY set at 10M and the other set at 100M, there should be detectable errors in the negotiation or data transfer. If you see errors in the registers on our PHY, perhaps you can use this as a case to reset the PHY using the RESET_N pin. When you trigger the abnormal behavior, do you see errors in the PDF (Parallel detection fault) register or in the Receive Error Latch register?

Best,

Shane

Hi Shane-san,

Thank you so much for your reply !

I understood about DP83826.

And about DP83848K,

only way to revent occurring from the phenomenon is to use " device RESET" by using RESET_N pin.

Is my understanding correct?

I suppose the best way for the customer is to consider to adopt DP83826.

Best Regards,

Takumi

Hi Takumi-san,

Takumi Suzuki1 said:

only way to revent occurring from the phenomenon is to use " device RESET" by using RESET_N pin.

This would be the best workaround we can offer. 

Best,
J

Hi J-san,

Thank you for your answer and I understood.

By the way,

I have asked the customer to consider to change the device.

The customer will consider the device.

Against, the customer asked me if TI can issue something document (like error report...) about DP83484K.

Is it possible to do this?

Thanks and Regards,

Takumi

Hi Takumi-san, 

To publish a documentation, we will need more conclusive evidence. However, without the design support and tools, it is very challenging to produce conclusive evidence to publish a documentation.

The team is now aware of this potential mode of failure, and will let the customers know should they try to use DP83848K in this particular mode. 

In the meantime, the team is recommending DP8382x series PHYs which have the resources and the design support in cases of failure to the customer. 

Best, 
J