DP83848T TX_CLK

This is an unusual phenomenon. It is not something I have seen before. Could you share some scope shots of the TX_CLK during the decay cycle and during normal operation on the same board?

If you could share a schematic of your design, I could also look that over to see if there are any suggestions that I can make.

Thanks,
Patrick

This is unusual indeed. How do I share these images with you?

I don't see a way to attach files and I have been unsuccessful in pasting the images into this message window. Please advise.

Thanks.

Bob Riehl

Bob,

To insert images, you select "Use rich formatting" (highlighted in red below).

Then you select "Insert/Edit Media" (highlighted in red below), select the image, set the dimensions and insert.

I hope this helps.

Patrick

Ok.  Not obvious to me.

330usec TX_CLK:

Normal TX_CLK, same scale:

TX_CLK at 20nsec/div:

Phy schematic:

3108.DP83848_Phy.pdf

I believe that you can save this file locally and view it.

Let me know if otherwise.

Thanks.

Bob Riehl

Patrick;

Any thoughts?  Are you as stumped as I am?

Should I just go ahead an replace the part?

Please advise.

Bob Riehl

So I replaced the part...and the same symptoms persist.

Of further note, RX_CLK stops at pretty much the same time as TX_CLK.  But 25MHz Out never misses a beat.

What causes TX_CLK to stop?  RMII mode would do it, correct?

Bob Riehl

Hi Bob,

This is strange behavior.  When the PHY's TX_CLK dies, can you stop the uC from hitting the RESET line?  I'd like to know if you can dump the registers in this state.  This would tell us if you are strapping into RMII mode.  Can you also share at least the PHY portion of the schematic?

If you are in RMII mode with a 25MHz clock, you will have some significant problems.

Best Regards,

I provided the Phy schematic previously (DP83848_Phy.pdf on March 28)  Just to leave no stone un-turned, I replaced R331 with a 1.5K to no avail.

Is there any register in particular that interests you?  I have scope plot indicating that TX_CLK tri-states after the MDIO transaction completes.

The hardware straps the Mode to MII, but there is a bit in one of the extended registers that can over-ride the strap and select RMII mode.

I believe that in RMII mode, the TX_CLK and RX_CLK are disabled, correct?

This transaction is controlled by ChibiOS.  This is the only board that behaves this way.

Bob Riehl

Bob,

The PHY RESET_N pin is active low. The 2.2 kOhm resistor R309 will hold the PHY in reset. What is driving the PHY RESET_N pin? That is to say, what is connected to the ETH_PHY_RST signal? Could you send a scope shot of this signal in relation to the TX_CLK and RX_CLK?

Patrick

Patrick;

Since the MCU IO pins are all inputs out for reset, the pull-down holds the Phy in reset until the MCU boots and eventually drives the line high.

Please note the yellow trace (Ch1 ) in the previous scope plot. This is the Phy reset line being driven high about 35usec before the MDIO transaction begins. Ch 2 is MDIO and Ch 3 is TX_CLK. Rx_Clk is the same as TX-CLK except for the exponential decay...RX_CLK hits the lower rail much more quickly.

Bob Riehl

Bob,

OK. I think you are on the right track regarding MDC/MDIO. It does look like that last register access disables the clock.

What are the register accesses that are being performed? In particular, what is that last register access?

Is there a way to prevent the register accesses? Could you disable them via software or disconnect the MDC/MDIO connections between the PHY and the MCU?

Patrick

Yes to all of the above, but not without much angst and consternation on the part of me and the software guys. All of the Phy code is bundled with ChibiOS and is not our code. It will take a fair amount of time to rifle through the bowls of the Phy driver to uncover what exactly is going on.

Again, this is the only board exhibiting this problem, it's not the Phy, it's not the MCU, it's not any of the peripheral discretes, it must be software, but I've never seen this type of behavior from software. Software bugs usually persist from board to board.

I believe that you have confirmed that this behavior can be replicated by setting bit 5 in the RBR register, correct? Are there any other bits that may cause this behavior?

Thanks.

Bob Riehl

Bob,

TX_CLK and RX_CLK are unused in RMII mode, but they will still toggle. If you set bit 5 in the RBR register, it would change the frequency of TX_CLK and RX_CLK, but they wouldn't stop toggling.

Below are some register bits that would stop the clocks:
Power Down (BMCR[11])
Isolate (BMCR[10])
Energy Detect Enable (EDCR[15]), if no Ethernet cable is connected.

Patrick

Bob,

Just checking in. Have you been able to determine that this is caused by a specific register access?

Patrick