An Ethernet PHY for the STM32F107 and STM32F4

A what? If you’ve never crossed paths with ethernet technologies before then you may not know what an ethernet PHY is. Well, it’s the physical transceiver that converts a well-known data-bus protocol implemented by your MCU into the physical signals that go down the wire.

MCU ethernet support

MCUs such as the STM32F107 come with a degree of ethernet support built-in. The MCU provides a 10/100Mbs MAC and can talk the standard Media Independent Interface (MII) protocol to the outside world.

This is where the PHY comes in. The PHY receives the 4-bit wide MII protocol and synthesises the differential signals necessary to drive the ethernet RJ45 socket. It also does the reverse, decoding incoming signals from the RJ45 connector and talking MII back to the MCU.

The MII protocol connections

This separation of concerns reduces overall cost by limiting the complexity of the components outside the MCU.

Other options

Only a minority of MCUs have ethernet support. The STM32F107 is one, the STM32F2 and STM32F4 series are others. Ethernet tends to feature in special series MCUs or newer and more expensive devices.

There’s an STM32F107 modestly hiding behind the faded print

If you don’t happen to have one of those then all is not lost. Companies such as Wiznet with their W5100 device have taken the logical step of integrating the MAC, PHY and the entire TCP stack into one IC. If you don’t have ethernet support on your MCU then this is what you could use, but it will cost a little more due to the increased feature set and the interface is likely to be serial which may limit performance.

Another option is to buy the ST official PHY add-on board for their F107 development board but it’s pricey, and it’s much more fun to build your own.

This article will focus on building a PHY targeted at the STM32F107 but compatible with any MCU that can talk the MII protocol.


There’s a few of them to choose from, and they’re all much of a muchness, I mean how exciting can you make an ethernet 10/100 transceiver? ‘Not very’ is the answer to that question. They all implement the basic protocol and then add various extras such as indicator LEDs, error detection and various types of auto-detection of your configuration.

The one I selected is the Micrel KSZ8051MLL, available at the time of writing from Farnell in single units for 86p. Yes, 86 pence is all you need to fork out for the core IC in a PHY.

The KSZ8051MLL in LQFP48 7x7mm package, 0.5mm pitch.

Features of the KSZ8051MLL

Here’s a functional diagram of the KSZ8051MLL taken from the datasheet that shows how it fits into the ethernet physical layer.

Functional diagram.

As well as providing the core PHY support the KSZ8051MLL has some useful extra features:

  • Interrupt support so we don’t have to continually poll the device to find out when something has happened.
  • LED outputs for link, speed and activity status.
  • Auto detection of straight-through and crossover cables so you can use either type. (I like this one!).
  • Power saving modes – ethernet is quite power-hungry when it’s active.
  • Diagnostics for detecting where a cable fault lies, and diagnostics for detecting pin-to-board faults.
  • Single 3.3V (or 2.5V or 1.8V) power input – the 1.2V regulator is built in.
  • On-chip termination resistors for the differential pairs.


Upon power-up or hard reset the PHY has to configure its internal registers with some default values. Rather than hardcode some defaults, the device uses the rather ingenious method of momentarily sampling the levels (high or low) of a selection of its pins and using those levels to configure the registers.

That means that a low-cost board could configure the PHY by setting appropriate pull-ups and pull-downs on the pins and thereby not have to write microcontroller code to configure the device through software. Code not written is flash memory not used is money saved.

Well, we have a micrcontroller and rather a good one at that, so we’ll be configuring the registers to known values through software after a hard reset.

A development board schematic

After reading the datasheet, and the application notes on Micrel’s website, I decided that a development board should not be too hard to design. The challenges would lie in creating a reliable, interference free design that could cope with the high-frequency ethernet signals.

I took Micrel’s reference development board schematic as a starting point and modified it to remove features that I wasn’t going to need, and to adapt it so that it would work with the external components that I was going to select.

The schematic. It’s too large to read on this page so click the image to open it in a PDF

Basic design features

The design follows the recommendations made in the Micrel application note for the PHY with some modifications made by myself to tailor it for use by a powerful MCU such as the STM32F107.

There are no jumpers for setting the hardware strapping options. We will accept the defaults provided by the internal pull-ups and pull-downs on the PHY and make any adjustments via register access after reset. In practice the only limitation of this approach is that the PHY ID number will be fixed at ‘1’ because there is no writeable register available to reconfigure this after reset.

All the PHY lines except the differential pairs are exposed in 2.54mm pin headers arranged around the board.

Decoupling of the power lines follows the advice in the application note and the datasheet, and we add 47µF of bulk capacitance to the board. Ferrite beads are used to suppress interference.
33Ω resistors are used on the MII signal lines to limit reflections. This design feature is also present in the Micrel reference design. The termination resistors that are commonly found between the differential TX/RX pairs and the PHY are not required in this design because they are integrated into the PHY itself.

The RJ45 connector

Ethernet design guidelines state that there must be a 1:1 isolation transformer between the cable and the PHY. These are known as the magnetics.

The TE Mag45 connector

Ethernet transformers are surprisingly expensive in small quantities so in my design I’ve chosen the TE 6605424-1 connector that integrates the magnetics and an ESD protection circuit into the connector.

The TE Mag45 schematic

RJ45 connectors that integrate the magnetics are commonly known as magjacks and are better value than buying the transformer and connector separately. Even so, this is the most expensive part in the design.

The clock

10/100 ethernet systems require a 25Mhz clock that runs at full speed for 100Mb/s operation and is internally divided down to 2.5Mhz when the link is set to 10Mb/s.

The 25Mhz crystal

The design allows for the 25Mhz clock to be sourced from an onboard crystal or from an external clock. In the former case R8 and R9 are solder bridges (or 0Ω resistors). In the latter case the clock should be applied to the XI pin and R8 and R9 are not connected.

I have chosen an Abracon ABLS-25.000MHZ-B2F-T crystal with an 18pF load capacitance requirement. The formula for choosing the values of the two load capacitors is well documented on the internet. It is:

C1 = C2 = 2 * CL - (CP + CI)

Where CP is the parasitic capacitance of the board and CI is the input capacitance of the PHY. For my Abracon crystal with its CL of 18pF this works out at C1 = C2 = 30pF, assuming the commonly quoted CP + CI = 6pF.

I’m a little concerned at the additional capacitance introduced by the presence of the XO and XI header pins. If the capacitance is too far from the ideal level then the crystal frequency will be off target or it may not even start oscillating.

I’ll be using my 1Ghz Ant18e logic analyser to check that the crystal’s output frequency is correct. I can measure the frequency at one of the PHY clock pins. Any attempt to measure it at the XI and XO pins will fail due to the the capacitance of the probes being added to the load capacitance seen by the crystal.

Bill of Materials

Here’s the full list of parts that I selected for this project. All of them are available from Farnell Electronics and I have included direct links to each part’s page at Farnell.

Identifiers Description Mftr. & Part No.
C2,C3,C6,C8,C9,C11,C12 MLCC, 0603, Y5V, 50V, 100NF MULTICOMP – MCCA000256
C4,C5 CAPACITOR, NP0, 0603, 50V, 30PF KEMET – C0603C300J5GACTU
C10 MLCC, 0603, X5R, 6.3V, 2.2µF MULTICOMP – MCCA000516
R5 RESISTOR, 0603, 4K7 5%, 0.1W PANASONIC – ERJ3GEYJ472V
C1,C7 CAPACITOR, X5R, 0805, 6.3V, 22µF AVX – 08056D226MAT2A
R1,R2,R7 RESISTOR, 0603, 220R 5%, 0.1W PANASONIC – ERJ3GEYJ221V
R10..R19 RESISTOR, 0603, 33R 5%, 0.1W PANASONIC – ERJ3GEYJ330V

PCB layout

The CAD for the board didn’t take too long. A few component footprints had to be created from scratch and I always route by hand these days.

The board CAD layout with layers merged

I only wish I’d had space on the top layer where the header pins are to label each pin with its function. Doing so would have exceeded the 50mm square limit that I was working to.

After designing the CAD I exported the Gerber CAM files and uploaded them to ITead Studio for manufacturing. A couple of weeks later they arrived.

The front of the board, looks great in red!

The differential TX/RX pairs are clearly visible snaking from the PHY to the RJ45 connector. The +/- lines are kept close to each other and have their lengths equalised as much as possible. Other signals, including the top ground pour are kept well away from these traces to help minimise interference.

I don’t do ground pours as a matter of course, only if the design calls for it and in this case the Micrel notes recommend it. I have seen reports on the internet of issues with prototype board manufacturing and ground pours that come into close proximity with other signals so I set a conservative 15 mil pour-to-trace clearance and removed ‘islands’ (areas of the pour that are not connected to a signal).

The back of the board

The back of the board contains the chassis and signal ground planes. Chassis ground from the RJ45 socket is isolated from the large central signal ground plane by an isolation moat. The break in the moat over on the right is to prevent a loop antenna being created.

The fully built PCB

The build process was fairly straightforward. I followed my usual procedure of reflowing on a hot-plate for the IC and any parts that have concealed pins. That meant the 47µF capacitor and the crystal in this case. Both of those do have enough of their pins protruding to hand-solder them but the majority of the pins are underneath so reflow is preferred. Also, their bases are plastic and would easily melt if they came into contact with an iron or an over-enthusiastic hot-air gun.

After reflow the remaining discrete components were simply hot-air’d into place with a pair of fine tweezers. The majority are 0603 size which is the smallest size I can work with both quickly and accurately. I can (and do) work accurately with 0402, but not quickly! The last steps are to use an iron to solder the headers and finally the RJ45.


I decided that the first stage of testing would be to simply verify that the thing is alive. By alive, that means that the clock is active and the PHY is responding to commands. So, I powered it up and wrote a small STM32 program that exercised the built-in NAND tree self-test mode.

This test involves first setting all pins high then pulling each one low in sequence and checking another pin to ensure it toggles from low to high or high to low. The result of the test was…


Nothing happened. The PHY appeared to be completely ignoring me. After much head-scratching I decided that the clock cannot have started so I got my multimeter out, set it to continuity testing mode and meticulously tested the pads on a blank board for continuity where it should be and none where it should not be.

Found it! On close inspection there is an unwanted connection between R9 and the ground pour. Furthermore as bad luck would have it the connection is very hard to see because it’s under the silkscreen label. It’s visible under the microscope though.

Bad Gerber!

At first I thought it was a manufacturing defect until, that is I checked everything in the chain and found that the Gerbers had been badly generated by the Camtastic Gerber generator. This is rather annoying since I followed the online guide for producing the Gerbers and it had all seemed fine.

I spent some time investigating the issue and it turned out to be an option in the Camtastic ‘Export Gerber’ dialog that was selected by default and should be deselected to avoid the bug:

Deselect this checkbox

Deselecting the highlighted option results in Gerbers that appear to be correct, at least as far as I can tell by inspecting them in the Viewplot preview program.

Anyway, the fix for the boards that have already been manufactured involves the surgical application of a sharp knife to break the unwanted trace and I’m back in testing mode.

That did the trick. This time the NAND test passed with flying colours and I can move on to measure the clocks.

Clock testing with a logic analyser. Click for larger

The PHY outputs a clock on TXC and RXC when in MII mode and the line is disconnected. At 100Mb/s (the default) this clock will be the full 25Mhz. I set my logic analyser to its maximum asynchronous sampling rate of 1GHz and measured both pins. As you can see from the image above they are both spot on 25Mhz. Perfect.

Software driver

ST publish sample code that is designed to operate with their ST802RT1 PHY. It demonstrates a point-to-point web-server using the lwIP TCP stack.

The project is laid out in the same structural form as every other ST sample that I’ve seen. As much as I dislike flat, procedural ‘C’ code, there’s a lot to be said for the predictable format that ST uses. Once you’ve seen one then you’ll know exactly where to look in all the others.

The key changes that I needed to make to the sample were to change some preprocessor definitions for the status register and speed and duplex masks. Around about line 354 of stm32_eth.h I added:

//#define PHY_SR 31         /*!< Tranceiver Status Register */
  * @brief  For DP83848  
//#define PHY_SR 16     /*!< Tranceiver Status Register */
  * @brief  For Micrel KSZ8051MLL
#define PHY_SR 0x1e     /*!< Tranceiver Status Register */

And slightly further on I added:

  * @brief  For DP83848  
//#define PHY_Speed_Status  ((u16)0x0002)    /*!< Configured information of Speed: 10Mbps */
//#define PHY_Duplex_Status ((u16)0x0004)    /*!< Configured information of Duplex: Full-duplex */

  * @brief  For Micrel KSZ8051MLL
#define PHY_Speed_Status    ((u16)0x0001)    /*!< Configured information of Speed: 10Mbps */
#define PHY_Duplex_Status   ((u16)0x0004)    /*!< Configured information of Duplex: Full-duplex */

With these in place all I needed to do was comment out the stuff related to flashing LEDs via the HTTP server because I’m only interested in testing the link and the data transfer. The sample code compiled OK and I uploaded it to the MCU.

Embedded web server. Click for larger (600kB) image

It works! The link with the netbook is auto-negotiated at 100Mb/s full duplex. The embedded lwIP protocol stack, hardcoded to IPv4 address, is configured to respond to ICMP ping requests which you can see in the command prompt window. More impressively you can see Google Chrome successfully downloading a web page from the embedded http server.

Final testing

I decided to do a final round of testing to ensure that the design is robust. The aim was to verify all the possible link modes and ensure that there were no errors received on the line – too many framing errors could indicate a signal integrity problem due to interference.

RX signal lines

I hooked up my logic analyser to the RXDV, RXER, RXC and RXD[0..3] lines and took some samples triggered on the rising edge of RXDV (data valid) line. The results are shown in the image above. I also left it running for about 10 minutes with a trigger on the RXER line (receive error) while flooding the local network with broadcast UDP packets. It was never triggered, indicating that the signal integrity was perfect.

I tested the following configurations and all performed as expected:

  • Auto-negotiation of speed and duplex
  • 100Mb/s full and half-duplex
  • 10Mb/s full and half-duplex
  • Straight-through and crossover cables (auto MDI/MDI-X).

An stm32plus driver?

It’s here! I’m happy to say that the KSZ8051MLL is one of the supported PHYs in the all-new TCP/IP stack included with stm32plus 3.0.0. Click here to read all about it.

Print your own PCBs

Want to have a go at assembling one of these boards yourself but don’t have a home etching kit? No problem, just download the Gerbers from my downloads page and use a service such as that offered by ITead Studio, Seeed Studio or Elecrow.

Version 2 now released

I have produced a new version of this development board that uses the popular Hanrun HR911105A connector and has a few other incremental improvements. See this article for a complete write-up.

  • Tim

    great job Andy!

  • sadatan vashistha

    Iam using ksz8051mll with stm32f207igt its working but when i ping it some time it works and some time it shows Request time out.

    • It's very hard to know what could be your issue because anything in the whole stack could be causing it. Try different link modes (full/half duplex 10/100Mbps). Look for errors on the RXER line. Try setting breakpoints in the ethernet code really low down to see if a 'lost' packet is received by the device but dropped in the software somehow.

  • Piet

    Would you please kindly share the sources for this project? The KSZ8051 seems to be great as it incorporates the resistors and is cheap 🙂

    • There is really no source code of my own. I just modified the ST demo (AN3102) as documented under "Software Driver" above.

      I see that ST have rearranged their website again and broken all the links again. So I've updated the hyperlink to the lwIP demo code in the article and it should work until the next time that ST decide that there are too many working links into their site and go and break them all again 🙁

      • j.h.

        What was the toolchain and environment?

        I recently downloaded the ST LwIP application note and demo (AN3102 and stm32026, respectively) and began porting to the F107VC with a Micrel PHY. There seemed to be more changes necessary than those listed above to even compile the vanilla project code.

  • MangoDan

    Hi Andy,

    I have built my PHY module using the same IC as you and connected to a STM32F4 Discovery. Also like you, on powerup nothing happens 😉
    I do not seem to have any shorts or open circuits, the NAND tree test works ok.

    What I am interested in is your comment about TXC and RXC emitting a 25MHz clock when the line is disconnected, by the line, you mean the ether net jack? The oscillator is running at what seems to be spot on 25MHz but I do not have any signal on TXC or RXC.

    • Yes I meant the ethernet jack when I said 'line'. Have you hooked it up to the ST sample code and had it initialise successfully? I can't recall exactly but you may have to configure the MAC in MII mode and issue a PHY reset before the clocks are generated.

      Set a breakpoint in ETH_Init() on the first line after this comment:

      /*——————– PHY initialization and configuration —————-*/

      The next few lines reset the PHY and try to bring the link up. If you get past the reset you can try to bring the link up and then you'll know for sure that it's OK.

      • MangoDan

        Ok thanks, I have not tried with the ST code as yet, I have tried with Chibios demo which I modified for the MII rather than RMII interface, but no success there.

        Only reason I've not tried the ST code yet is they do not ship it with any make files, so I'll have to make my own (don't like using the GUI's, just a text editor and make command) so not got anything setup to try the ST example as is. I'll either make some make files, or try setup Eclipse at some point and try it out.


        • MangoDan

          I've ported the code from the in application firmware update example. The thing seems to mostly work, but not quite!

          It manages to send packets over the wire when used with a cross over cable, as my router sees the dhcp request and sends a response. However the MCU never sees the response, instead it sees its own data! The packet it sent. With a straight through cable the packet never gets to the router, and the MCU doesn't see its own packet.

          This seems a tad strange and at first I thought I must have got something wrong with the wiring to the MagJack, but I have checked this and it seems fine.

          Any ideas what it might be?

          • That's a bit weird. Are you setting the 'broadcast response' bit in the DHCP packet flags? You should be, and if you are then you can spy on the response from the router using dhcpdump from another linux box on your network to check that it's actually going out. tcpdump works just as well but dhcpdump does a great job of prettifying the packets.

            I'm also surprised that the straight cable doesn't work as the PHY has MDI-X auto-cable detect. Now that you've got comms working you can read those PHY registers to see what's going on.

          • MangoDan

            I had not had a chance to look at this for a while, but on a fresh look i found the problem was really quite simple! the pullup resistor on the interupt line was missing. I also changed a couple of register addresses for dealing with interupt config. Now the IAP demo works at least as far as showing the file upload page :).

  • TraK


    it's the first time i come on this forum and i'm pretty pleased to see what's you doing. Great job!

    I don't know the ARM based MCU because i'm working with ATMEGA and ATXMEGA.

    What you did it's a cheaper XPORT no ? (lantronics 1st price on farnell start at 45€). But the XPORT speed is limited at 921600 baudrate max. Did your board goes at higher speed ?

    Do you know if it's possible to do ATMEGA + ethernet project with your board?

    Thanks for your answer and have nice day and go on like this !

    PS: Sorry for my English it isn't my 1st language 🙂

    • Hi,

      XPORT is a highly integrated device that incorporates the PHY, MAC and TCP/IP stack in firmware. This project is just the PHY. It's designed to connect to a fairly powerful device such as the STM32 that already has the MAC built in and has sufficient resources to run a TCP/IP stack in firmware.

      XPORT exposes a serial interface to the network stack that's limited to around 1Mb/s. The PHY interface in this project supports 100Mb/s MII (4 bits transferred per 25Mhz clock tick). The STM32 will transfer data out of, or into its ethernet FIFO at 100Mb/s but internally the speed limit will be how quickly the DMA channel can fill or empty that FIFO.

      Finally, this will not work on one of the low-end 8-bit Atmega devices because they don't have a MAC and probably not enough SRAM to support the buffer and caching requirements of a network stack.

  • can i disable the oscillator in the PHY power save mode. Will the PHY detects the cable insertion( energy) without oscillator?

    oscillators are drawing around 40 mAmps of current. I want to reduce the power by switching off the oscillator whenever there is no cable plugged In.

    • The datasheet says that the lowest power mode will leave only the MII interface active. That means the energy-detect functionality is off and you'll need to bring it back to life with a command from the MAC, probably a software reset. You might want to try it to confirm that though as the datasheet does not go into enough detail for my liking.

  • jhinkle

    Andy – nice post.

    Was there a reason you did not use a 25mhz oscillator instead of the crystal? The 8051 says it can accept an external clock and I did not see Micrel says not to use one (I did find another mfg that suggested not to because noise may introduce jitter). Just wondering what your thought process was on clock selection.

    I'm an old fart (retired) just getting into using SMD. I have a toaster over for reflow. You commented that you place 0603 parts. I was going to limit myself to 0805 parts to make things easier on my eyes — comments as to any negatives associated with that choice.

    I am doing multiple project using the Freescale K60. (ARM with Ethernet MAC). I also elected to use the 8051 PHY but since I'm using a 100 pin package for the CPU – it limits me to MMIR. I was going to combine the both on one board — but after reading your post – I'm going to separate them into two boards (as you have done here).

    Can you point out what Micrel App note informed you about ground pours? I ask because I found an App note from another PHY mfg that suggested things differently than what I see on your board. By the way — thanks for showing your board — great learning example for someone like me that has only laid out a couple of boards in the past — never one with ground pours.

    Again – thanks for sharing this project.

    • Page 50 of the datasheet gives examples of both crystal and oscillator connections. I selected a crystal because they're much cheaper than oscillators and I have some past experience with them, basically I was pretty confident it would work so I went with it.

      The main advantage I find of 0603 vs. 0805 is just the obvious one – I can pack them more densely if I need to. I find them both really easy to put down with a pair of tweezers and hot air but like you said it's down to where your comfort zone lies.

      The application note is AN-139:

      You have to extrapolate somewhat from the 4-layer example in the note but the principals are clear. Not creating an antenna loop out of the chassis ground is just general knowledge.

  • jhinkle

    Thanks – I had read the one from Micrel — it doesn't really speak to 2 layer.

    I know you are already done — but I'll share another layout guideline that speaks to 2 layer construction. It states not to place a ground plane under the rj45 connector or the routed RX and TX differential lines. The ground plane increases distributed capacitance associated with the transmission line (the traces).

    Google gives a direct PDF link so I just coped the name — you can then Google it if you like,

    "AN 18.6 – SMSC Ethernet Physical Layer Layout Guidelines"

  • Kiss Dávid

    Hello Andy! First of all, thank you for the great post! I try to ethernet phy getting work in my own project, i use Micrel KSZ8031RNL TR. The NAND three test dosen't work, evry condition ok, i measured it.. I think my code don't work. Can you share your own NAND test function?

    • Hi David, thanks for your comments.

      You can find the code fragment I used for testing here:

      It is quite old now and compiled against my stm32plus library version 1.2.0 but you should be able to translate the logic into whatever library you are using.

      • Kiss Dávid

        Thank you! But i'm afraid, this code not contains the PHY register settings and for me it would be the problem. Can you post this few rows? Thank you again!

        • Are you still referring to the NAND test? The register settings are irrelevant for the NAND test because the test only verifies basic connectivity.

          Anyway, you can get the entire LWIP project source code that I used in this article from here:

  • Kiss Dávid

    Yes, NAND test only verfifies the connections, but you must set a register to enable NAND tree test mode.

    • Ah, now I understand your question. On the KSZ8051MLL you can also enable the NAND mode by pulling INTRP/NAND low during reset. You can see that I do this in the reset function so when reset is deasserted the PHY goes into NAND test mode.

      See page 24 of the datasheet: "enable NAND tree mode by either hardware strapping (which is what I do) or software register (which I do not do)."

      • Kiss Dávid

        I solved the problem. My code was perfect, but i needed to pull LED0 pin up. When i did this, the test ran well. This PHY caused a lot of headaches, QFN24 package, RMII interface with 50 MHz signals, but finally operate. Thanks!

        • Well done, I'm pleased that you finally got it working.

  • Luc

    Hello Andy,

    Nicely done. Thanks for all the information.

    I am presently designing a board with the same KSZ8051MLL PHY and I will be using the new STM32F427 which has 2MB of flash and 256KB of Ram. We want to set it up on .NET Micro Framework.

    1) I was just wandering if you did a line impedance matching for your traces between the PHY and the STM32. Is your 33 ohm resistance line impedance matched or just a value to limit reflection?

    2) How about your differential traces between the PHY and the Magjack. Are they impedance matched to a differential impedance of 100 ohm?

    Kind Regards,

    • Hi Luc, thanks for your comments. Your project sounds like an interesting one, it'd be nice to see it when it's done.

      Regarding your questions. The values in the schematic were based entirely on the reference schematic from Micrel – I figured they knew best when it came to their own device. Anyway, search google for "ksz8051mll reference schematic" and it should come up as your first hit.

    • harry

      Hello Luc,

      any news about this NETMF project ?
      it is very intresting.


  • Philip Virgil

    Hello Andy,

    I just want to clarify. Is that the only line you changed in stm32_eth.h? Did you also change the value of the PHY basic control registers? By the way I'm using KSZ8873MLL.

  • STM324ME

    Today I just received a End-Of-Life notification for KSZ8051MLL, they will not make any more after 02/28/2014

    Luc, you might want to change your plans

    • Luc Landry

      I also received it, but I think that there is replacement (KSZ8081MLX)

      kind regards,

  • BoLi


    Can you upload footprint ? I want to take your footprint as a refference.

    Bo Li

    • Do you mean the footprint for the KSZ8051MLL or the Gerbers for the whole board? If you mean the whole board then yes I can do that – check back after the weekend and I'll have them uploaded by then.

  • Monica

    Hi Andy,

    This is an awesome article! Thank you for sharing!


  • BO LI

    I notice that there are two 30PF capacitors around the 25MHz crystal. The original eval kit for this chip using the 22pf, is that make any difference? Also, there has a push botton on the reset pin originally.
    And I have another question, in the original eval kit schem, There has like a regulator MIC5207YM5 which switch from 3.3 to 1.2, so it is not necessary right?

    • Hi,

      The value for the caps around the crystal depend on the required load capacitance of the crystal (specified by the manufacturer) and the additional external capacitance of the board, traces etc. I give the calculation that I used in the article. The EV kit may have used a crystal with different capacitance or their board materials may be different.

      I don't need a push-button reset because this board is intended for connection to an intelligent MCU that will be able to do the software reset on startup. See the hardReset function in stm32plus for example.

      It's not necessary to have a 1.2V supply, the KSZ8051MLL has an internal 1.2V regulator. I suspect they copied that part of the EV kit design from an earlier model that may not have had the internal regulator.

  • Rick

    So I must use PHY chip to connect magjack to STM32F107, it can't be connected directly stm32F107 ==>magjack….
    can I use ENC28J60 as PHY chip ? thanks

    • That's correct. The MAC (in the STM32F107) connects to the PHY and the PHY connects to the cable. The ENC28J60 cannot be use in this way. It is an all-in-one MAC/PHY solution for devices that don't have a MAC.

  • Rick

    do you still have the spare PCB and KSZ8051MLL chip ? I'm interested to buy…

    • Hi Rick, sorry not at the moment. However do check back in a few weeks because I'm planning to publish a new article on the first weekend in April with a redesign that uses the popular Hanrun MagJack. At that time I will have some more boards available, populated and unpopulated.

      • Rick

        Ok, let me know if you have the board, I'm interested thanks

  • praveen kumatr

    how ethernet link up and down is identified with lwip stack

  • Pingback: interface ARM controller (say STM32F4) to Internet()

  • Rick

    Hi Andy, should I use external 25MHz crystal on STM32F107VCT6 and change
    the configuration for clock and using 8MHz crystal ? I’m using DP83848
    module with 50MHz clock output….What do you reckon ? thanks