STM32 Ethernet looks simple when a board has an RJ45 jack and a generated CubeMX project. In practice, reliable LAN firmware depends on a chain of details: the MAC inside the MCU, the external PHY, RMII or MII signals, clocks, DMA descriptors, memory placement, cache behaviour, TCP/IP middleware, and field diagnostics.
That is why many STM32 Ethernet projects pass a first ping test and still fail under real traffic, long cable runs, DHCP changes, or noisy industrial power. The fix is not one magic setting. The fix is treating the hardware and firmware as one Ethernet system.
This guide explains the practical checks that make STM32 Ethernet more stable. It draws on ST’s own guidance for a bare-metal HAL Ethernet application and the official STM32CubeMX configuration tool. It also connects the design work to Progressive Robot services for DevOps services, workflow automation, business process automation, and production readiness planning.
| Area | What to verify |
|---|---|
| Hardware | MAC-capable MCU, PHY, magnetics, RJ45, reset, straps, and reference clock |
| Interface | RMII pinout, MDIO/MDC access, GPIO speed, and alternate functions |
| Middleware | LwIP, NetX Duo, or bare-metal HAL depending on product needs |
| Memory | DMA descriptors, buffer alignment, SRAM region, heap, and cache rules |
| Testing | Link state, ARP, ping, TCP/UDP load, packet counters, and recovery |
What STM32 Ethernet really includes
STM32 Ethernet usually means the microcontroller provides an Ethernet MAC, while an external PHY handles the physical signaling on the cable side. The MAC is responsible for frame handling, DMA movement, filtering, interrupts, and the connection to the software stack. The PHY negotiates link speed and duplex, drives the copper interface, and exposes status through MDIO registers.
That STM32 Ethernet split is important because a board can have the correct MCU and still fail if the PHY wiring, clocking, reset, or strap pins are wrong. A firmware team can also have clean LwIP code and still lose packets if DMA memory is in the wrong SRAM region or cache maintenance is incomplete.
A useful mental model is to divide the design into four layers. First is board hardware: PHY choice, power rails, magnetics, RJ45, oscillator, reset, and PCB layout. Second is peripheral setup: RMII or MII, clocks, GPIO speed, MDIO, interrupts, and MAC address. Third is packet movement: descriptors, buffers, DMA, cache, and heap. Fourth is networking behaviour: ARP, IP assignment, TCP, UDP, HTTP, MQTT, diagnostics, and reconnect logic.
This layered view prevents STM32 Ethernet blame from bouncing between hardware and software. If the link never comes up, start at PHY power, clock, reset, straps, and MDIO reads. If link is up but no packets arrive, inspect RMII pins, DMA descriptors, interrupts, and receive counters. If packets arrive but the application stalls, inspect memory ownership, stack configuration, RTOS priorities, and socket handling.
MAC, PHY, RMII, and clock choices
STM32 Ethernet reliability starts with the MAC-to-PHY boundary. Many STM32 boards use RMII because it needs fewer pins than MII. ST’s Ethernet guidance notes RMII can use seven pins compared with sixteen pins for MII on supported boards. That pin savings is attractive, but it makes the 50 MHz reference clock and pin configuration especially important.
The PHY must be selected early. Common designs use parts such as LAN8742-style PHYs on development boards, but production boards may choose a different device for availability, temperature range, power, package, diagnostics, or automotive/industrial requirements. The firmware should not assume every PHY behaves exactly like the evaluation board.
Clocking deserves special attention in STM32 Ethernet. RMII needs a valid reference clock shared correctly between the MAC and PHY. Depending on the board, that clock may be generated by the PHY, by the MCU clock output, or by an oscillator. A marginal clock can create intermittent failures that look like software bugs.
Pin configuration matters too. Ethernet pins should use the correct alternate function and very high GPIO speed where required. MDIO and MDC must work so firmware can read the PHY registers. Reset and strap pins need clean timing so the PHY boots into the expected address and mode.
For a custom STM32 Ethernet PCB, do not treat the RJ45 and magnetics as generic parts. Check the PHY reference design, impedance, differential routing, isolation, ESD protection, Bob Smith termination where applicable, and power filtering. A stable LAN product begins before CubeMX generates any code.
CubeMX, HAL, LwIP, and bare-metal paths
STM32 Ethernet projects often start in CubeMX because it can configure the pinout, clock tree, peripheral options, middleware, and initialization code. That is useful, especially for teams that need a repeatable starting point. CubeMX reduces manual STM32 Ethernet setup mistakes, but it does not remove the need to understand what the generated code is doing.
The common software path is HAL plus LwIP. HAL initializes the peripheral and manages low-level driver operations. LwIP provides the TCP/IP stack for ARP, IP, ICMP, UDP, TCP, DHCP, DNS, HTTP, MQTT clients, and other network behaviour. Some STM32 families and examples also use NetX Duo or RTOS-aware middleware.
A bare-metal path is also possible when the product needs direct frame control or when the team wants to understand the peripheral without a full TCP/IP stack. ST’s HAL example for H5 and H7 devices demonstrates configuring Ethernet pinout, transmit descriptors, receive descriptors, PHY interaction, frame construction, and callbacks without leaning on middleware.
That STM32 Ethernet comparison is useful. LwIP is the better fit when the device needs real IP networking. Bare-metal frame handling is better for learning, diagnostics, special protocols, or constrained systems that only need link-layer behaviour. Choosing the wrong path can waste weeks. A product needing MQTT over TCP should not rebuild a network stack from scratch. A product needing a narrow deterministic frame exchange may not need the overhead of a full middleware stack.
Teams should document the selected path early. Include the MCU family, PHY, Cube firmware package, generated project settings, LwIP version, RTOS decision, checksum offload settings, heap and stack assumptions, and which code sections may be regenerated safely.
DMA descriptors, buffers, and memory placement
STM32 Ethernet failures often hide in DMA descriptors and receive buffers. STM32 Ethernet is not a simple byte stream copied by the CPU. Frames move through MAC, MTL, DMA, descriptors, and memory blocks. If those blocks are too small, misaligned, inaccessible to DMA, or affected by stale cache lines, the network can behave unpredictably.
ST’s bare-metal guidance highlights the need to size receive buffers and descriptors correctly. A normal Ethernet frame can be about 1524 bytes without jumbo frames, and the required heap space depends on the receive buffer length multiplied by the number of receive descriptors. In the example, four receive buffers of 1524 bytes produce a 6096-byte requirement before rounding up.
That arithmetic is only the start. On Cortex-M7 and some high-performance STM32 families, cache coherency becomes a major design issue. DMA writes data to memory, but the CPU may read stale cached data unless buffers live in a non-cacheable region or the firmware performs correct cache maintenance. Transmit buffers can fail in the opposite direction if the DMA reads memory before CPU writes are cleaned.
STM32 Ethernet memory placement must be explicit. Confirm which SRAM banks are DMA-accessible on the chosen MCU. Check linker scripts, MPU settings, descriptor alignment, section attributes, and whether generated code places descriptors in the intended region. Avoid accidental moves during refactoring.
Buffer ownership is another trap. The network stack, HAL driver, DMA engine, and application may all touch packet memory. A reliable design defines when a buffer is allocated, handed to DMA, consumed by the stack, released, and reused. Missing one ownership transition can create rare failures that only appear under burst traffic.
Debugging link, packets, and interrupt failures
STM32 Ethernet debugging should move from physical link to packets to application behaviour. Do not start by changing random LwIP options. Start with STM32 Ethernet evidence.
First, read the PHY link state through MDIO. Confirm link up or down, negotiated speed, duplex, and whether autonegotiation completed. If the PHY cannot be read, inspect MDIO/MDC, PHY address straps, reset, clock, and power. If the PHY reads correctly but link is down, inspect cable, switch port, magnetics, and mode settings.
Second, confirm the MAC and DMA are running. ST’s debugging guidance points engineers toward key Ethernet registers, including DMA debug and channel status registers. These can show whether transmit and receive state machines are active, stopped, or blocked by unavailable buffers or bus errors.
Third, use external visibility. A managed switch, port mirror, Wireshark capture, and a known-good PC can reveal whether ARP, ICMP, UDP, or TCP frames are actually on the wire. If the board never answers ARP, the problem is below the application socket layer. If ARP works but TCP fails, focus higher in the stack.
Fourth, instrument STM32 Ethernet callbacks and counters. Print link transitions, descriptor errors, receive counts, transmit completion events, DHCP state, IP address changes, and socket errors. For long-running products, expose at least a small diagnostic page, serial command, or telemetry counter set.
Finally, test failure recovery. Unplug the cable, change switches, reboot the DHCP server, send broadcast traffic, run long pings, and apply TCP/UDP load. A product that only works after reset is not field-ready.
Production checklist for reliable LAN firmware
A production STM32 Ethernet design needs more than a demo. The first production STM32 Ethernet check is identity. Every shipped device needs a unique MAC address strategy. Do not clone the same development MAC across a product line. Decide whether addresses come from an assigned block, secure manufacturing data, external EEPROM, OTP, or a provisioning database.
The second check is configuration. Decide whether the product uses DHCP, static IP, fallback addressing, hostname rules, DNS, NTP, VLANs, or service discovery. Make those choices visible to installers and support teams. Network bugs become expensive when nobody knows how the device is supposed to join the LAN.
The third check is security. Many STM32-class systems have limited RAM and flash, so TLS, certificate storage, secure update, and authenticated control channels must be planned early. If the device exposes HTTP, MQTT, Modbus TCP, or a custom protocol, define the threat model before deployment.
The fourth check is observability. A field technician should be able to tell whether link is up, an IP address was acquired, packets are flowing, DNS works, and the server is reachable. This is where embedded networking connects with DevOps services: production firmware needs logs, metrics, rollback strategy, and release discipline.
The fifth STM32 Ethernet check is process. Treat firmware builds, board revisions, network test scripts, packet captures, and issue reports as a controlled delivery workflow. Teams that already use workflow automation and business process automation can apply the same discipline to embedded validation: repeatable tests, clear gates, and documented handoffs.
STM32 Ethernet FAQ
Do all STM32 microcontrollers support Ethernet?
No. Only selected STM32 families and part numbers include an Ethernet MAC. Many devices still require an external PHY, magnetics, RJ45 connector, and correct board layout before wired networking is possible.
Is RMII better than MII?
RMII is often preferred because it uses fewer pins, but it depends on correct reference clocking and board design. MII uses more pins and may be useful in specific designs, but RMII is common on STM32 development boards.
Should I use LwIP or bare-metal HAL?
Use LwIP when the product needs standard IP networking such as DHCP, TCP, UDP, HTTP, or MQTT. Use bare-metal HAL when the goal is low-level learning, custom frame handling, diagnostics, or a narrow link-layer application.
Why does ping work but TCP fail?
Ping only proves part of the path. TCP can still fail because of heap limits, buffer sizing, retransmission behaviour, checksum settings, RTOS priority issues, socket misuse, or server-side problems.
What is the most common custom-board mistake?
Clocking and PHY setup are frequent causes. Check the 50 MHz RMII reference clock, PHY address straps, reset timing, MDIO/MDC access, GPIO alternate functions, and very high speed pin settings before blaming the TCP/IP stack.
STM32 Ethernet can be extremely useful for industrial controllers, gateways, test equipment, robotics, and connected products that need deterministic wired connectivity. The strongest STM32 Ethernet projects treat the feature as a complete system: board design, generated setup, driver behaviour, buffers, middleware, diagnostics, and deployment process.
If your team needs help turning a prototype into a reliable connected product, contact Progressive Robot to review architecture, testing, automation, and production rollout before networking bugs become field failures.
