DP83848M: PHY is turning on but is not communicating with our external switch.

Hi Luc, 

Can you verify that pair A of the PCB is connected to the pair A of the receiver and likewise for the other pairs? Also, you cannot access the MDIO registers on the PHY? Having an access to MDIO registers will be very helpful for the debug. Also can you confirm if the switch works with the laptop?

Best,
J

Yes absolutely, I've tripple checked the RJ45 cable connections. I've also swapped them jsut for fun and nothing changed. In case auto-mdx is diabled but it should be on as per strap pins.

No I'm having a hard time with the code. I couldn't find any source code so I was using chatgpt to create some basic functionality like reading device ID but it isn't working. I'm using a SAMV71 as the MCU which is connected to the GMAC interface. If you have any code handy that I can plug in that would be helpfull.

The switch doesn't work direct to a laptop either no.

If the switch does not work with a laptop also, I think this is a switch problem then. Is this switch managed or unmanaged?
To read registers, we often directly connect MSP430F5529 launchpad which we flash with firmware to interact with USB2MDIO (TI-made SW for MDIO read/writes).

The laptop would be connecting to the switch on-board IC through the same PHY that I'm having an issue with. I don't see the LED for LINK activate at all and according to the strap pins it should indicate if there is even a link from the PHY to the router/laptop. I said external switch earlier but I really meant a router sorry, and when I talk about a switch IC I'm talking about the SJA1105RELY switch IC. It goes laptop/router -> PHY -> SJA1105RELY -> MCU.

I have the MDIO and MDC pins connected to the MCU's GMDIO and GMDC pins respectively. I wouldn't be able to connect an external device because I don't have an extra access port, I'm working on a new prototype so I could connect the signals to a pin header? Do you know of any github repos maybe that would have some sample code? If I can successfully send it commands to send it back diagnostic data and print it out over UART terminal that be helpful.

Hi Luc, 

Unfortunately, I do not know of any repo for the MCU. 
I agree that it is weird that Link LED is not activated. When the cable is unplugged and probe pair A and B, do you see first link pulse signal on either pair? Also, have you checked RST_N and RBIAS pin according to the troubleshooting guide?

Best,
J

I can see that something is going on but our scope isn't fast enough to see acctual pulses at those speeds. I see large +/- 12V pulses in a weird alternating waveform. I'm guess it's becuase our scope isn't fast enough to see the reality. This is when I probe the A B pairs. If I probe the other side of the magnetics which go into the PHY I see a completly different waveform it looks more like a solid line with pulses that go to GND here and there. I will try to get scope readings for you tomorrow.

I looked on the product page but I dn't see a troubleshooting guide, is it part of the datasheet?

Hi Luc, 

I apologize. I got confused with another product. Is RST_N pin LOW when you probe it?

It is weird that you are seeing 12V pulses. FLPs look like the image below and is a repeating pattern and this pulse repeats every 16ms so I think most scopes should be able to capture the waveform:

The pulse should be around 2V. What probe are you using to measure the waveform?

Also, if you are alternating signal, I think that may be because there is a link. 

Best,
J

I got a few scope screenshots. The first one you can see 10V/div and it's pretty crazy. This is when I have the Ethernet cable plugged into the router and I'm measuring the TX_P signal before it goes through the magnetics on the pcb, and then on the other side of the magnetics between the magnetics and the phy you can see a mostly solid 3.3V signal with some little peaks heee and there.

If I don't plug the Ethernet cable into the router, there is absolutely nothing on either side of the magnetics, only a gnd signal.

I also included a video of the phy booting up when power is first applied. The link and speed lights light up briefly. 

Hi Luc,

The waveform looks like it is transmitting 100M Ethernet signal. That signal is MLT-3 signal which 100M ethernet uses to transmit. As you are seeing that signal instead of FLP, I would like to say that the PHY is in link. As to why the LEDs are acting up, I am unsure. I know you cannot get MDIO access but it would be a lot easier with it. 

I am also unsure why its 10V/div but that can be due to your probe magnifying signals by 10 times. 

I looked at the schematic again and it looks like LED connection for the PHY is not there. How are the LEDs connected?

Best,

J

The only thing I'll add is that this signal only occurs when the PHY is plugged into the router. When it is unplugged I only see a flat ground signal and I don't ever see the pulse you where referring to earlier. I'm trying to get MDIO working.

The first photo I sent you is mostly flat with some peaks, that is measured between the magnetics and the PHY, does that one look normal to you given that the second photo that is measured between the magnetics and the router look normal?

I had my probe at 10x and the voltage was much lower, when I changed it to 1X I had to set it to 10V/div to I could see the whole signal.

Sorry for the confusion, I gave you a schematic where I've fixed some of the issues with the PHY already, and that schematic was the next prototype we're going to build.

This is the original one with some of the issues we already fixed such as: the power_down pin being held low (I put a jumper wire to pull it high when the main power comes on); there's no bob-smith termination on it currently; the PBFOUT pin was not connected to PFBIN1 and 2 so I soldered a wire to make the connection.

 4380.Ethernet PHY.pdf

I removed the LEDs in the schematic you where looking at because in the final version of this board we didn't want the LEDs.

Hi Luc, 

I zoomed into the first photo and it looks like the peak is periodic. This seems to be FLP. The image I sent you is a lot more zoomed-in image of FLP. 
Because the second waveform comes out when you connect, I am fairly certain that there is a link with the PHY and the router. 

For the LED, it might be showing that behavior because of the 2.2k resistors. DP83848 has auto polarity detection and your design does not meet either of our configuration:

And I noticed yours is similar to AN0=0 configuration but it is pulled to VCC.

I know the LEDs are broken, but have you tried transmitting/receiving packets?

Best,
J

Oh okay that makes sense. The only other reason why I didn't think there was a link is because on the router the green light doesn't turn on, which apparently indicates if there's a link. I figured if the LEDs where wrong on the PHY at least the lights on the router would light up.

This is a screenshot of the datasheet that I have. I am using the DP83848MPHPEP and when I go to mouser.ca and click on the datasheet I get this one: DP83848-EP PHYTER Military Temperature Single Port 10/100 Mbps Ethernet Physical Layer Transceiver datasheet (Rev. E)

I haven't tried tried that since we've applied a few different fixes. I will try that tomorrow when I get to the lab.

Hi Luc, 

It is weird that the router link LED is not lighting up. However, the waveform seems to indicate that there is a link. 
For the datasheet, please refer to this datasheet: https://www.ti.com/lit/ds/symlink/dp83848m.pdf?ts=1769628509285&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDP83848M

DP83848 is an old device so we do not have much documentation available, but there is a chance DP83848-EP and DP83848M have different features with LED so I would suggest to refer to the datasheet above. 

Please keep me updated. 

Best,
J

Will do, I'll let you know what happens with sending data.

I checked the datasheet you mentioned and the exact part name I have matched the datasheet I had before, whereas the new one you mentioned isn't quite the same "DP83848MSQ". I also notice that the package on the new one isn't the same as the part we orderd, and there is no alternative package that matches the IC we have. The new datasheet has a different number of pins as well. I think the one I had before dp83848-ep is the right one because it matches the package and number of pins.

Hi Luc, 

I see. I didn't realize DP83848-EP is also a DP83848M variant. Thank you for checking on that. In this case, the LEDs should be fine as you followed the datasheet recommendation. I looked at the schematic again and I am unsure why the LEDs are acting up in this case. Have you probed the 3V3 when the PHY is being turned on to ensure that the rails on the LED are 3.3V at all times?

Have you tried enabling communication on the PHY? 
Also, you only need one pullup on MDIO bus. I noticed that both PHYs have MDIO pullups. 

Best,
J

I'm going to try to communicate over it today but I think I see that pulse you where talking about more clearly now. I also don't see 12V anymore I see 5V. I changed to a better oscilloscope.

Between the PHY and the magnetics I see this pulse repeated over and over again.

I am trying a direct PC connection now to rule out the router and I have an ethernet to USB connector which connects directly to the laptop. There are still no lights. Between the ethernet adaptor and the magnetics I see this repeated constantly. 

The reset pin is HIGH at 3.3V. What did you mean by enabling communication on the PHY, just disengaging the reset pin?

Hi Luc, 

Thank you for the waveform. 

Based on this, it looks like the link is not being established for some reason.

Luc Charbonneau said:

What did you mean by enabling communication on the PHY, just disengaging the reset pin?

I meant it as try sending packets. 

However, in this case, there is no link established so you will not be able to do anything. 

As a sanity check, could you verify your post-magnetics to the RJ45 connector connection is like below?


Also is auto-mdix enabled or disabled on DP83848?

Best,
J

I had rx and tx swapped so I re-soldered them just to see, but auto-mdix is enabled. 

The labeling on the pcb is accurate, the only thing I don't have on the magnetics is the Bob-Smith terminations. Could that be the issue? I had tried this cable between my laptop and router to make sure it wasn't faulty and it worked fine, I then stripped one end and soldered it to the pcb as you see in the photo. 

Hi Luc, 

Missing bob smith termination can impact signal integrity. Because you are not using standard RJ45 also, all of these factors can cause the link to be not up. 
Based on your waveform also, I notice that there is no dip after the peak. This makes me think that there may be too much loss causing FLP to not be caught by the LP. 

Best,
J

I added bob smith termination and it still isn't working. I can see a little bit of noise on the bob smith termination so it's doing something. This is the scope reading on the TX side of the bob smith termination.

This is the signal on the TX_P mangetic/connector side. This is the signal on the TX_P magnetic/PHY side. Those don't look like they changed.

I also noted that if I leave the router or PC unplugged I don't see those little pulses at all. I'm thinking that the TI PHY should be sending out those pulses regardless if the router/pc is plugged in right? Because it should be trying to see if there's a router or PC plugged in. On the router or PC side there would also be another PHY which is sending those pulses.

I'll also add that I jerry riged the resistors and cap for the bob smith termination with some wires. Electrically everything is connected properly, but it also isn't a nice PCB trace as close as possible to the magnetics. I'm not sure if that would be a big problem.

I have a new prototype PCB for ethernet being made with all of the fixes I've applied so far coming in a week or so, so there won't be any jerry rigged fixes on it like this current prototype.

Hi Luc, 

Luc Charbonneau said:

I also noted that if I leave the router or PC unplugged I don't see those little pulses at all. I'm thinking that the TI PHY should be sending out those pulses regardless if the router/pc is plugged in right? Because it should be trying to see if there's a router or PC plugged in. On the router or PC side there would also be another PHY which is sending those pulses.

Your understanding is correct. So, when the router/PC is not plugged in, you are not seeing any pulses coming out on any of the MDI lines? If this is the case, the PHY may not be functional. 

Luc Charbonneau said:

I have a new prototype PCB for ethernet being made with all of the fixes I've applied so far coming in a week or so, so there won't be any jerry rigged fixes on it like this current prototype.

Sounds good. If the issue persists, we can continue debugging on the new board. 

Best,
J

I'm still working on the GMAC code. Is there any hardware way to confirm if the chip is broken? I would solder a new one on, but they're expensive and I only bought enough for the new board. I'd be willing to solder a new one on this prototype if I can confirm if it's damaged.

Hi Luc, 

I don't think the PHY should be broken since you previously saw the waveform below when the cable was connected to the router:


If you could check RST_N pin is high and 25MHZ_OUT is being outputted with 50MHz, that should be a sign that the PHY is alive. 

Best,
J

Hey!

We got some feedback from GMAC and here are the results. We have access to a command line interface we can probe all the registers in the PHY. Is there anything you'd like me to check specifically?

"

TCP/IP Stack: Initialization Started

ETH PWR ON

PHY3 RESET

ETH SWCH ON

TCP/IP Stack: Initialization Ended - success

miim

Usage: miim <netix n> <add a> - Set the network interface index and PHY address

Usage: miim <start r> <end r> - Sets the start and end register (decimal) for a                                                                                                                                    dump op

Usage: miim <read rix> - Reads register rix (decimal)

Usage: miim <write rix wdata> - Writes register rix (decimal) with 16 bit data (                                                                                                                                   hex)

Usage: miim <dump> - Dumps all registers [rStart, rEnd]

Usage: miim <setup> - Performs the PHY setup

Usage: miim write_smi rix wdata - Extended 32 bit SMI write using rix (hex) and                                                                                                                                    wdata(hex)

Usage: miim read_smi rix - Extended 32 bit SMI read using rix (hex)

>miim start 0

miim: Set Start Reg to: 0

>miim end 16

miim: Set End Reg to: 16

>miim dump

>Miim dump: 0, netIx: 0, add: 0, val: 0xffff

Miim dump: 1, netIx: 0, add: 0, val: 0xffff

Miim dump: 2, netIx: 0, add: 0, val: 0xffff

Miim dump: 3, netIx: 0, add: 0, val: 0xffff

Miim dump: 4, netIx: 0, add: 0, val: 0xffff

Miim dump: 5, netIx: 0, add: 0, val: 0xffff

Miim dump: 6, netIx: 0, add: 0, val: 0xffff

Miim dump: 7, netIx: 0, add: 0, val: 0xffff

Miim dump: 8, netIx: 0, add: 0, val: 0xffff

Miim dump: 9, netIx: 0, add: 0, val: 0xffff

Miim dump: 10, netIx: 0, add: 0, val: 0xffff

Miim dump: 11, netIx: 0, add: 0, val: 0xffff

Miim dump: 12, netIx: 0, add: 0, val: 0xffff

Miim dump: 13, netIx: 0, add: 0, val: 0xffff

Miim dump: 14, netIx: 0, add: 0, val: 0xffff

Miim dump: 15, netIx: 0, add: 0, val: 0xffff

Miim dump: 16, netIx: 0, add: 0, val: 0xffff"

Thank you,

Luc Charbonneau

Those are the values on page 55 of the datashhet. Registers 0 through 16.

How can I add someone else I work with to this post so they can reply? He's gonna be taking over from here.

Hi Luc, 
It looks like all the register values are not valid. Could you see if the PHY could have been strapped to the wrong address by reading the other PHY addresses?

I am unsure how you can add the post, but I am sure they can continue answering on the same post. 

Best,
J

Hi J,

Luc got me in on this problem, and I have dumped all the registers using MIIM command line commands.

I believe the register values you see seem to be coming from the device directly, as we tried other PHY addresses and in those cases the MCU failed to communicate at all with the PHY chip.

All 28 registers dumped can be seen below. 

Nader

...

Hi Nader, 

I see. Is this happening from the new prototype board, or is this still the old one?

Best,
J

We are on the old prototype still, he is going to get the new one built in the next couple of days, will send updated register values then.

If there is anything else you would like me to try with this old board, please let me know.

Thanks,

Nader

Hi Nader, 

I have a sense that the PHY is either held in reset or broke. 
Could you check if RST_N pin is high or low? Also, could you check 25MHz_OUT pin gives out a clock signal?

Best,
J

Hi J,

The 25MHz_OUT pin seems to be actively outputting a clock signal, and the RST_N is high (meaning the device should not be held in reset).

Thanks,

Nader

Hi J,

I realized I was attempting to dump the wrong PHY address, among some other issues with the switch. But with those things fixed, it seems we got a successful register dump of the PHY:

>Miim dump: 0, netIx: 0, add: 7, val: 0x1000
Miim dump: 1, netIx: 0, add: 7, val: 0x7849
Miim dump: 2, netIx: 0, add: 7, val: 0x2000
Miim dump: 3, netIx: 0, add: 7, val: 0x5c90
Miim dump: 4, netIx: 0, add: 7, val: 0x de1
Miim dump: 5, netIx: 0, add: 7, val: 0x 0
Miim dump: 6, netIx: 0, add: 7, val: 0x 4
Miim dump: 7, netIx: 0, add: 7, val: 0x2801
Miim dump: 8, netIx: 0, add: 7, val: 0x 0
Miim dump: 9, netIx: 0, add: 7, val: 0x 0
Miim dump: 10, netIx: 0, add: 7, val: 0x 0
Miim dump: 11, netIx: 0, add: 7, val: 0x 0
Miim dump: 12, netIx: 0, add: 7, val: 0x 0
Miim dump: 13, netIx: 0, add: 7, val: 0x 0
Miim dump: 14, netIx: 0, add: 7, val: 0x 0
Miim dump: 15, netIx: 0, add: 7, val: 0x 0
Miim dump: 16, netIx: 0, add: 7, val: 0x4000
Miim dump: 17, netIx: 0, add: 7, val: 0x 0
Miim dump: 18, netIx: 0, add: 7, val: 0x 0
Miim dump: 19, netIx: 0, add: 7, val: 0x 0
Miim dump: 20, netIx: 0, add: 7, val: 0x 0
Miim dump: 21, netIx: 0, add: 7, val: 0x 0
Miim dump: 22, netIx: 0, add: 7, val: 0x 100
Miim dump: 23, netIx: 0, add: 7, val: 0x 21
Miim dump: 24, netIx: 0, add: 7, val: 0x 0
Miim dump: 25, netIx: 0, add: 7, val: 0x8027
Miim dump: 26, netIx: 0, add: 7, val: 0x 904
Miim dump: 27, netIx: 0, add: 7, val: 0x 0
Miim dump: 28, netIx: 0, add: 7, val: 0x 0

Hi J,

I did a quick datasheet check on these values and they all seem to be good. Link status is "down" in the relevant registers which makes sense since we read the registers while the PHY was disconnected.

I also checked the LED mode, and observed them when attempting to connect to an ethernet switch via RJ45, and they did not behave as expected (link LED did not activate). This leads me to believe there may be a hardware issue between the PHY and the ethernet cable, but I'm not 100 percent sure.

For now, we will build up the new prototype and get back when we've tried working with it.

Thanks,

Nader

Hi Nader, 
It looks like the PHY is alive. 
Can you do a register read when you connect the PHY to a link partner? Reading register 1h will tell us if the PHY is linked up or not, instead of looking at link LED. 

Best,
J

Hi J,

Just did another dump with the PHY connected to a switch, the dump returned the same values. Seems the link is still down:

>Miim dump: 0, netIx: 0, add: 7, val: 0x1000
Miim dump: 1, netIx: 0, add: 7, val: 0x7849
Miim dump: 2, netIx: 0, add: 7, val: 0x2000
Miim dump: 3, netIx: 0, add: 7, val: 0x5c90
Miim dump: 4, netIx: 0, add: 7, val: 0x de1
Miim dump: 5, netIx: 0, add: 7, val: 0x 0
Miim dump: 6, netIx: 0, add: 7, val: 0x 4
Miim dump: 7, netIx: 0, add: 7, val: 0x2801
Miim dump: 8, netIx: 0, add: 7, val: 0x 0
Miim dump: 9, netIx: 0, add: 7, val: 0x 0
Miim dump: 10, netIx: 0, add: 7, val: 0x 0
Miim dump: 11, netIx: 0, add: 7, val: 0x 0
Miim dump: 12, netIx: 0, add: 7, val: 0x 0
Miim dump: 13, netIx: 0, add: 7, val: 0x 0
Miim dump: 14, netIx: 0, add: 7, val: 0x 0
Miim dump: 15, netIx: 0, add: 7, val: 0x 0
Miim dump: 16, netIx: 0, add: 7, val: 0x4000
Miim dump: 17, netIx: 0, add: 7, val: 0x 0
Miim dump: 18, netIx: 0, add: 7, val: 0x 0
Miim dump: 19, netIx: 0, add: 7, val: 0x 0
Miim dump: 20, netIx: 0, add: 7, val: 0x 0
Miim dump: 21, netIx: 0, add: 7, val: 0x 0
Miim dump: 22, netIx: 0, add: 7, val: 0x 100
Miim dump: 23, netIx: 0, add: 7, val: 0x 21
Miim dump: 24, netIx: 0, add: 7, val: 0x 0
Miim dump: 25, netIx: 0, add: 7, val: 0x8027
Miim dump: 26, netIx: 0, add: 7, val: 0x 904
Miim dump: 27, netIx: 0, add: 7, val: 0x 0
Miim dump: 28, netIx: 0, add: 7, val: 0x 0

Thanks,

Nader

Hi Nader, 

Thank you for the confirmation. 

Could you write 0x0000 = 0x0100 and 0x2100 to see if the PHY links up? 

0x0100 should link up to 10M and 0x2100 should link up to 100M. 

I want to see if linking up at all is an issue, or if auto-negotiation is an issue. 

Also can you verify XI clock is 50MHz with 50ppm?

Best,
J

Which register would you like me to write those values to?

I wrote 0x0100 and 0x2100 to register 0, and the link did not activate.

Going to check the clock.

Thanks

Nader

Can confirm clock is 50 MHz.

Thanks,

Nader

Hi Nader,

Is there a way for you to check if the frequency of the XI clock is within 50 ppm? 

If the XI clock is within ppm requirements, I believe this is an issue with the Ethernet cable.

Best,

J

Hey! Good news, I soldered the new board and the PHY works. The lights show up on the router indicating a stable link, and the GMAC commands show that the link is up as well.

Thank you for your help, you've been very helpfull.