STM32 W5500 Ethernet Tutorial Part 2 – TCP Server in Blocking Mode
In this tutorial, we’ll take the next step and create a TCP server on STM32 using the W5500 module.
⚙️ STM32 + W5500 Ethernet — TCP Server Tutorial
This tutorial shows how to turn an STM32 microcontroller plus a W5500 Ethernet module into a TCP server. The server listens for incoming TCP connections, echoes received data back to the client, and uses the data to control a hardware component (for example an LED) on the STM32 board.
🧰 What the project covers
Using the W5500 module via SPI to interface with the STM32.
Setting up the socket in TCP mode, binding it to a port, listening for connections, accepting a client, then using recv() and send() (or the equivalent library calls) to receive and echo data.
Turning client data into physical actions on the STM32 (e.g., if the data says “LED ON” the MCU sets the LED output accordingly).
Discussion of blocking mode operation (the server waits for data) and its limitations (while waiting, other tasks might be stalled).
Short-term mention of the next step (e.g., integrating an RTOS or non-blocking mode) to make the system more responsive.
📋 Why it matters for makers
This is a practical example of how a hardware TCP/IP off-load module (the W5500) can be used in embedded systems to provide wired Ethernet connectivity—even on MCUs that don’t have built-in Ethernet. It demonstrates how networked communication and simple embedded logic (LED, GPIO) can be combined, which is perfect for makers building IoT devices, remote monitoring, or control systems with high reliability (since wired ethernet tends to be more stable than WiFi).
🧭 Basic workflow
Wire the SPI interface between the STM32 and the W5500 (MOSI/MISO/SCLK/CS, plus RESET/IRQ if used).
Configure the MCU peripheral (SPI, GPIO, maybe UART for debug) in your development environment (e.g., STM32CubeIDE).
Include or integrate the W5500 driver library (initialise the chip, check link status, set IP or DHCP).
Create the socket in TCP mode, bind it to a chosen port, listen for connections.
When a client connects, receive data. Echo that data back or parse it to control hardware (e.g., LED).
When the client disconnects or errors, close or reset the socket and wait for the next connection.
Recognise the limitations of blocking mode and plan for future improvements (non-blocking mode, RTOS tasks, multiple clients).
✅ Strengths & ⚠️ Things to watch
Strengths:
Demonstrates wired Ethernet usage on cost-effective MCU + W5500 combo.
Connects network communication with real embedded control (LED switching).
Clearly written and good for makers just getting into Ethernet hardware.
Considerations:
Blocking mode means while waiting for network data the MCU may not be free to do other tasks.
Supports one client per socket when configured this way; multiple concurrent clients will require more sockets or advanced logic.
Ensure correct wiring, grounding and voltage levels for stable SPI/Ethernet performance.
If you plan production-scale use, consider adding error handling, timeouts, reconnections, and potentially RTOS or non-blocking patterns.
Created by: the tutorial author at ControllersTech
⚠️ Disclaimer: This tutorial was developed and published by ControllersTech. We are featuring it here to inform and inspire the maker community. All credit belongs to the original author, and we do not claim ownership or rights over this content.

