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.

DP83848I does not work properly?

Other Parts Discussed in Thread: DP83848I

Hi,

I am in front of a critical decision, use the DP83848I in the production stage or not.
The PHY controller seems to work well when it be connected to a low cost router, switch or in a point to point with a PC, seems that distance is not a problem when employing large cables. The surprise is when it is connected to the network of our office. Seems that the three Gigabit elements two routers and a switch does not tolerate the traffic from the DP83848I interface (even when using just "2 pair" cables). Any clue?

Only certain designs works well in all environments tested. Even the same design works well as a prototype assembled in laboratory and when I produce 10 prototypes in factory that fails in the above scenario (Gigabit elements). The difference: prototype has a controlled substrate (FR4 approx. 4.2Er), factory employed a general substrate.
The rest is equall, all capacitors X5R, X7R, same AVX tantalum, 1% on critical resistors...

The story:

A legacy design that I have modified (apparently worst design) works better than the modified one!. The inclusion of a bigger and powerfull DC/DC converter for the supply would be the principal reason, but if I disconnect the converter and supply system form an Agilent bench power supply the Ethernet works equally.

I have based the present design on the reference board:
http://www.national.com/assets/en/boards/dp83848_mau_enduro_schematic.pdf

Adding some capacitors like in the magnetics center tap. A difference observed and used from legacy schemes is the separation of the ground plane and the chassis plane. I recently split the Magjack GND and its body GND without any difference on behavior.

A repeated issue in the forum due to the source clock is not the reason of the failure. The clock is well generated by the RMII of an STM32 and is very clean and in a comparison of the clock FFT between good and bad boards all is exactly the same.

I attach a photo of the board:

Following the recommended guidelines:

4 layer board: from top to bot: 1-signal/gnd, 2-GND, 3-Power (in figure), 4 signal/gnd. 

And here a comparison table based on another post:

Pin Description     Factory DC value    DC value (good board)        DC value (bad board)

15

AGND 0 Volts 0 Volts 0 Volts
18 PFBIN1 1.73 to 1.8 Volts 1.785 Volts 1.756 Volts
19 AGND 0 Volts 0 Volts 0 Volts
22 AVDD33 3.3 Volts  3.312 Volts 3.328 Volts
23 PFBout  1.73 to 1.8 Volts 1.785 Volts 1.756 Volts
24 RBIAS 1.19 to 1.2 Volts 1.194 Volts 1.186 Volts
29 RESET_N 3.3 Volts 3.309 Volts 3.328 Volts
35 IOGND 0 Volts 0 Volts 0 Volts
36 DGND 0 Volts 0 Volts 0 Volts
37 PFBIN2 1.73 to 1.8 Volts 1.785 Volts 1.756 Volts
47 IOGND 0 Volts 0 Volts 0 Volts
48 IOVDD33 3.3Volts 3.312 Volts 3.328 Volts

The out of the 1.8V regulator it is on range but is lower than the good one, however the Rbias voltage it is low.

What is the reason?, Is this the origin of the failure?,  How could I solve it?

Thanks in advance. 

Daniel

 

  • Hi Daniel,

    I am moving your question over to the Ethernet forum so that they can help you with this. Please use this forum for your Ethernet questions moving forward.

    Thanks!

    John

  • Thank you for providing a great depth of detail on the history of your efforts.  Could you provide a bit more information on the issue you are seeing?  Specifically, could you clarify the type of cable you are using ("2 pairs cables)?  Could you also note the network devices that cause problems for connections as well as details of what happens (no link, blinking link, etc.)?

    Patrick

  • Hi Patrick,

    I have used all type of cables, quite often 4 pair cat 5e cables. The 2 pair cable was used in the supposition that the problem were in the other gigabit pairs but was not, it fails equally.

    All led signals are ok even 10/100 autonegotiation led. Link LED always it is ok , Activity LED works well at least when it receives. The following step is to debug in the software to investigate if the packet is received and if the processor reach the send state (ICMP for ping). But I would bet that the software works fine. Anyway we are going to debug to get more info.

    The issue observed is in my opinion due to "low level" causes:

    - Between several circuits with the same BOM and Layout, same firmware (web server) at a same location in the network: certain circuits response to ping and web services and others no.

    Following all the elements of the network seems to the "blocking" elements are the gigabit switch (first element encountered), and investigating a bit more the three gigabit elements (one per one appart) rejects the packets of the dp83848I (only in the fail boards of course). May be casuality the gigabit feature?, the other common feature is that all are Netgear. But note that the same circuit with a controlled substrate works well (components quality may be slightly better, but not in critical ones).

    I have some experience into RF and microwave world and in my opinion a substrate with a small variation on its permittivity would not produce appreciable changes at this frequency in special with coplanar lines and differential pairs.

    I have no idea of the cause, the interfaces works barely well but not enough.

    Link pulse shape seems equal between valid and failing boards, the differential pulses (link and carrier) are small in failing boards about 160 mVpp.
    I attach images for 1/2 link pulse (positive). The blue one corresponds with the valid boards, the yellow one with the failed boards.

                  

    What about the voltages on the 1.8V regulator and Rbias? Seems that all failing boards have less voltage with the same tántalum. Is this dependant of the loss/parasitics in the substrate? 

    Daniel