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.
Hello,
we use DP83848YB part on our equipment.
On few cases (4 up to now), the equipment came back from our customer and not pinging any more at 100Mb/s, but pinging correctly at 10Mb/s (full duplex in both cases).
When looking more closely on the PMD TX signal, the output signal is no more at 1V peak (as observed on correct equipments) but at 240mV peak (timings are not so bad).
Note: At 10Mb/s, the link pulses are similar in both cases (~2V peak).
I have some oscilloscope plots if you want.
Question : what can cause such behavior?
Note: the part under investigation is a National Semiconductor one.
Thanks,
Benoît
Hi Benoît,
Just want to confirm if my understanding is correctly.
--
Thank you,
Hillman Lin
Hi Lin,
thank you for your response.
Something like 12000 equipment are working correctly at 100Mb/s.
3 equipments were working correctly and passed tests at 100Mb/s when the equipment were shipped to the customer.
But these 3 are no more able to communicate at 100Mb/s.
Phy register 0x04 (ANAR) value is 0x01E1, for a correct and a failed equipement.
Sorry, but I am unable to add an oscilloscope capture file in pdf, png or jpg mode. I got a message "The file or URL is not allowed to be inserted". What is the procedure?
Thank you,
Benoît
Hello,
I work alongside Hillman. He will be able to continue this discussion starting next week as TI is on Good Friday/Easter Holiday.
Sincerely,
Gerome
Hi Benoit,
Are you able to copy paste directly to the chat instead of inserting it to upload the Oscilloscope capture?
--
Regards,
Hillman Lin
Hi Lin,
Yes, it works...
For the bad unit, it is a 250mV peak signal, not symetric:
And for the good units, it is a 1V peak symetric signal:
Both captures are performed using the same high speed differential probe.
It seems to me that next step is to check the voltage between transceiver and pulse transfomer, and verify it is too low (meaning the transformer is ok but the transceiver is KO).
And next step to removed properly the transceiver and test the board with a new one. The old transceiver should be send to TI for analysis.
Any other idea?
Thank you for your time,
Benoît
Hi Benoit,
Yes, checking the voltage between transceiver and transformer would help to get a better understanding rather is the transformer issue.
Could you also check the voltage in 10mbps?
--
Thank you,
Hillman Lin
Hi Hillman,
the link pulse signal at 10Mb/s is similar at 2V peak for both cases (good/bad board). That is why I suspect the transceiver but not the transformer
For the good board (2.2V peak):
And for the bad board (2.1V peak):
Thank you,
Benoît
Hi Benoit,
Could check the register 0x0000 to 0x001E for both good parts and bad parts to see is there any status different between the two?
--
Thank you,
Hillman Lin
Hi Hillman,
For both good and bad parts:
- @0x00 BMCR = 0x3100
- @0x1E Reserved= 0x003F
Benoît
When linked through Ethernet link to the test bench:
----------------------------------------------------
| Register | Good board | Bad board |
----------------------------------------------------
|Phy_reg@0x00 BMCR | 0x3100 | 0x3100 |
|Phy_reg@0x01 BMSR | 0x786D | 0x786D |
|Phy_reg@0x02 PHYIDR1 | 0x2000 | 0x2000 |
|Phy_reg@0x03 PHYIDR2 | 0x5C90 | 0x5C90 |
|Phy_reg@0x04 ANAR | 0x0DE1 | 0x0DE1 |
|Phy_reg@0x05 ANLPAR | 0x45E1 | 0x45E1 |
|Phy_reg@0x06 ANER | 0x0007 | 0x0007 |
|Phy_reg@0x07 ANNPTR | 0x2001 | 0x2001 |
|Phy_reg@0x08 Reserved | 0x0000 | 0x0000 |
|Phy_reg@0x09 Reserved | 0x0000 | 0x0000 |
|Phy_reg@0x0A Reserved | 0x0000 | 0x0000 |
|Phy_reg@0x0B Reserved | 0x0000 | 0x0000 |
|Phy_reg@0x0C Reserved | 0x0000 | 0x0000 |
|Phy_reg@0x0D Reserved | 0x0000 | 0x0000 |
|Phy_reg@0x0E Reserved | 0x0000 | 0x0000 |
|Phy_reg@0x0F Reserved | 0x0000 | 0x0000 |
|Phy_reg@0x10 PHYSTS | 0x4015 | 0x6815 |
|Phy_reg@0x11 MICR | 0x0000 | 0x0000 |
|Phy_reg@0x12 MISR | 0x2C00 | 0x2E00 |
|Phy_reg@0x14 FCSCR | 0x0000 | 0x00FF |
|Phy_reg@0x15 RECR | 0x0000 | 0x0009 |
|Phy_reg@0x16 PCSR | 0x0100 | 0x0100 |
|Phy_reg@0x17 RBR | 0x0021 | 0x0021 |
|Phy_reg@0x18 LEDCR | 0x0000 | 0x0000 |
|Phy_reg@0x19 PHYCR | 0xB021 | 0xB021 |
|Phy_reg@0x1A 10BTSCR | 0x0904 | 0x0904 |
|Phy_reg@0x1B CDCTRL1 | 0x0000 | 0x0000 |
|Phy_reg@0x1D EDCR | 0x6011 | 0x6011 |
|Phy_reg@0x1E Reserved | 0x083E | 0x083E |
|Phy_reg@0x1F Reserved | 0x0000 | 0x0000 |
----------------------------------------------------
Thnak you for your analysis,
Benoît
Hi Benoit,
Thank you for sharing the information. I will try to analysis the result and get back to you as soon as possible.
--
Sincerely,
Hillman Lin
Hi Benoit,
Are you able to reach out to the FAE on this question. They should can connect you to the quality expert in TI that can help you regarding to the IC quality issue.
--
Thank you,
Hillman Lin
Hi Hillman,
TI customer support (Archie A.) ask me to go on the E2E forum.
I am now pretty sure that Ethernet tranceiver is damaged. But we would like to understand what can cause such damage, in order to improve our product or the use of our product.
I should have the oscilloscope trace at tranceiver output at the end of the day.
I have a question in mind: is there any non volatile data inside the transceiver that may be sensitive to SEU event?
Thanks,
Benoît
Here are the oscilloscope's screen shots on the bad board for 100Mb/s:
and at 10Mb/s:
Benoît
Hi Benoit,
I discuss with the team internally with your questions. It seems to be a chip quality issue since 3/12000 of your units is damaged for 100mbps. It would be better to talk with the quality experts regarding to the problems you are facing right now. Did you have an Field Application Engineer assign to your account? If so, they can provide you a quality experts regarding to your problems.
Since only 3/12000 are damaged in 100mbps, it seems like board design issue is not the major concern. Some of the chip is damaged internally. Quality experts would be a best approach in your case.
Thank you for your understanding.
--
Regards,
Hillman Lin