32F4xx + LAN8742 PHY + RJ45 - best location for PHY?

[nctnico]

What kind of line driving resistors should be placed into the signals going from the LAN8742 to the integrated-magnetics RJ45?

The signals are "analogue" so should not be square wave at this point.

I would think probably nothing should go in there. But is there really no harmonic content?

There is harmonic content for sure. Keep the option open to insert 0402 parts. Starting out with 2.2 Ohm is a good idea. Another option is to use ferrite beads like 10 Ohm but with their peak dampening above 125MHz. Tune so EMC is barely met in order to allow maximum cable lengths in combination with poorly designed switches. Using a random 0402 ferrite bead is not going to work; these will need to be carefully selected and specified.

[dietert1]

Those connections are terminated transmission lines. Nominal impedance is 100 Ohm (see Wikipedia).
Any other part you insert there will cause reflections and thus hamper transmitted signal quality. The effect of additional 2.2 Ohm resistors will be small though, maybe comparable to reflections at a connector.

Regards, Dieter

[nctnico]

Those connections are terminated transmission lines. Nominal impedance is 100 Ohm (see Wikipedia).
Any other part you insert there will cause reflections and thus hamper transmitted signal quality. The effect of additional 2.2 Ohm resistors will be small though, maybe comparable to reflections at a connector.

Nope. There is a rather large tolerance on the impedance. Also keep in mind that the highest frequency on 100mbit ethernet signal is 125MHz; not super critical. You will want to control harmonics going out of the chip though and block HF spikes (surge and ESD) getting in from the outside. Hence the use of ferrite beads or small series resistors. If you dig deeper into application notes for ethernet phys you'll see that inserting series resistors or ferrite beads is the recommended approach to meet EMC requirements.

[dietert1]

I would rather wonder what happens with no ethernet connected to your RJ-45 and thus no termination. The resonance of those open-ended 10 or 20 cm stubs will be like 400 to 200 MHz or so and depending on the exact geometry you may be unlucky to miss your EMI specs in that case. As the transmitter includes local termination, we are considering a 6 dB effect.

Regards, Dieter

[peter-h]

With no cable, the software will not enable the LWIP connection to start with.

Also, in EMC compliance testing, you will be required to have a cable.

If I put in resistors, and perhaps beads also, their value can be increased as needed.

[nctnico]

I would rather wonder what happens with no ethernet connected to your RJ-45 and thus no termination. The resonance of those open-ended 10 or 20 cm stubs will be like 400 to 200 to  MHz or so and depending on the exact geometry you may be unlucky to miss your EMI specs in that case. As the transmitter includes local termination, we are considering a 6 dB effect.

It is not a problem. In general the signalling is only enabled after link negotiation. No link = no signal. In a very specific case you can set 100Mbit without auto-negotationg but this also disables auto-mdix. I can not imagine a situation where you'd disable auto negotation on purpose.

[peter-h]

Just realised I need resistors only on the two wires driven from the LAN8742. The two wires going to the LAN8742 inputs don't need this, I presume...

[nctnico]

Just realised I need resistors only on the two wires driven from the LAN8742. The two wires going to the LAN8742 inputs don't need this, I presume...

The PHY probably has auto-mdix so either pair can be the driver.

[tellurium]

Probably not an option, but if you're on a design stage, did you consider replacing LAN824x PHY with the W5500 MAC+PHY?
The W5500 is about 1 dollar more expensive, but it make is possible to use any micro, so is extremenly portable, and also saves some RAM since ST's MAC won't be used, so no DMA buffers, etc.

[peter-h]

Thanks for the suggestion, but I can't change this now. I have a rock solid LWIP implementation, tested over several years.

The W5500 is nice though. Via SPI, not fast, but most embedded stuff does not need multi megabit plus data rates. I've just implemented LWIP - WFM200S and that runs over 5MHz SPI, even polled for status (no interrupts) and for what I am doing (GDL90 UDP, DHCP, and such, and running my HTTP server for config) this is loads fast enough. So one saves a load of GPIO.

How old and debugged is it? I know some of those chips were buggy as hell.

[nctnico]

The W5500 has been around for a while. There is also an IPV6 model (W6600 IIRC). The libraries which come with it are to be treated as example; roll your own production code. But that isn't difficult. I'd take using a Wiznet chip over LWIP any day.

[peter-h]

roll your own production code

I am familiar with that concept

Days and hundreds of posts, and getting beaten up by "Piranha" on the ST forum... When one gets this stuff working, life is too short to change it. It may be "open source" but that just means "no support" + "weeks spent on forums". The people who actually know how to do it are never posting their code openly, because it belongs to their employer. The code that is public is mostly hacks, just to get you started.

Perhaps nowadays Claude digs up good code. It certainly did well on the WFM200S.

I do like the idea of an SPI PHY though.

I'd take using a Wiznet chip over LWIP any day.

People do say LWIP code is a mess, but it does work. It's had ~17 years of pretty broad deployment, and almost no fixes in the last 5-10 years. Whereas nobody knows what is inside these modules.

[ejeffrey]

I've been using the w5500 in a couple of devices for years now with many units in heavy 24/7 use.  I did use the wiznet libraries as is -- not only their socket library but also their dhcp client.  They aren't small, but in my case that wasnt a problem. They could easily be stripped down further.  I did play with their HTTP server a bit.  It worked but did use a lot of memory and also was hamstrung by the limited number of sockets. 

They have been rock solid.  They are easy to get running if you are used to socket programming.  I haven't had a problem related to the ethernet system.

Its not super fast but way faster than a serial port.

[tellurium]

That W5500 chip implements socket API via SPI. It supports up to 8 IPv4 sockets.
So a TCP/IP stack is not required, that was the whole idea behind Wiznet chips.

However the TCP/IP implementation inside those W5500 has limitations - no TLS, no IPv6, only 8 sockets, etc etc.

There is a possibility to overcome them: create only one socket and put it into the RAW mode. That turns the W5500 into a dumb Ethernet frame transciever and totally bypasses W5500's TCP/IP stack. Meaning, one must run a TCP/IP stack like LWIP on the host. So suddenly you can get IPv6, TLS and other goodies on plain old W5500.

Here is the example of W5500 usage on 8-bit Arduino Nano every with 6k of RAM, with TCP/IP stack running on the host (so it does NOT use W5500's built-in TCP/IP stack). The stack is Mongoose of course:

[peter-h]

It still doesn't deal with anything if one has a tested and working system, with LWIP in my case. The LAN8742 costs about £1.50, IIRC. It is also easy to shut down with a software command to save power, which I do when power fail is detected, when implementing a data save feature in the FLASH. I posted the details in another thread. A lot of work went into characterising that.

There are multiple ways to do this job but the stuff is so complex, so incredibly hard to debug, and there is so little support or even reliable information online, and the sw is license-free, that once one gets it working it is poor business risk to change it.