How to Build a Maker Modbus TCP Server with WIZnet W5500 on STM32F4?
This article explains a firmware-oriented Maker project based on STM32F4, WIZnet W5500, TCP server operation, and standard Modbus communication.
1. Title
How to Build a Maker Modbus TCP Server with WIZnet W5500 on STM32F4?
2. Summary
This article explains a firmware-oriented Maker project based on STM32F4, WIZnet W5500, TCP server operation, and standard Modbus communication. The GitCode project is described as a resource package for bringing up STM32F4 + W5500 TCP server communication with standard Modbus, intended to help a microcontroller communicate stably with a Modbus client over Ethernet. In this architecture, the STM32F4 runs the application firmware and Modbus logic, while the W5500 provides the wired Ethernet interface, hardwired TCP/IP stack, socket engine, MAC/PHY, and packet buffering.
3. What the Project Does
The GitCode project page identifies the project as a STM32F4 W5500 TCP server / standard Modbus communication resource package. Its description says the project helps users build network communication functions and achieve stable data transmission between a microcontroller and a Modbus client. It also states that the project is suitable for STM32 microcontrollers equipped with network modules such as W5500.
At the firmware level, the project can be understood as a wired Modbus TCP server design. The STM32F4 firmware initializes the board peripherals, configures the W5500 over SPI, opens a TCP server socket, waits for a Modbus client connection, receives Modbus requests, maps those requests to local data or device state, and returns Modbus responses. The W5500 handles the Ethernet transport layer, while the STM32F4 firmware handles application behavior.
For a Maker project, this is useful because it gives a practical bridge between embedded I/O and PC-side or HMI-side Modbus tools. A user can connect sensors, relays, GPIO, ADC channels, or simulated register values to the STM32F4, expose those values through Modbus registers or coils, and test the device from a Modbus TCP client over wired Ethernet.
The expected data flow is:
STM32F4 local I/O or test data → firmware register map → Modbus TCP response → W5500 TCP socket → Ethernet client.
In the reverse direction:
Modbus TCP request → W5500 receive buffer → STM32F4 socket read → Modbus parser → application state update.
4. Where WIZnet Fits
The WIZnet product in this architecture is W5500. WIZnet describes W5500 as a hardwired TCP/IP Internet controller that connects to an external MCU through SPI, supports high-speed SPI up to 80 MHz, integrates a 10/100 Ethernet MAC and PHY, supports TCP, UDP, ICMP, IPv4, ARP, IGMP, and PPPoE, provides eight independent sockets, and includes 32 KB internal memory for Tx/Rx buffers.
In this project, W5500 is not just a physical Ethernet adapter. It is the network offload boundary. The STM32F4 firmware does not need to implement the full TCP/IP stack in application code. Instead, it configures the W5500, opens sockets, sends and receives bytes, and focuses on Modbus request handling.
This division is especially useful for Maker firmware because the project remains understandable. The user can separate the system into three layers:
STM32F4 board firmware and peripheral logic.
W5500 Ethernet and socket transport.
Modbus TCP request/response protocol.
W5500 also provides practical constraints that the firmware must respect. The eight-socket limit means the project should define how many clients are allowed. The 32 KB internal Tx/Rx buffer memory means the firmware should avoid unbounded transfers and should keep Modbus frame handling deterministic. The W5500 product page also notes that W5500 does not support IP fragmentation, so firmware should avoid relying on fragmented IP packets for application behavior.
5. Implementation Notes
The GitCode page verifies the project topic and W5500 usage, but the visible indexed content does not expose complete source files or detailed implementation code. Therefore, this section does not claim exact file paths, function names, or code snippets from the repository. It provides a firmware-level integration outline consistent with the verified project description and official WIZnet references.
A practical STM32F4 + W5500 + Modbus TCP firmware can be divided into these modules:
Board bring-up: system clock, GPIO, SPI, chip-select pin, reset pin, UART debug output, and optional LED indicators.
W5500 driver layer: SPI read/write callbacks, W5500 reset sequence, network parameter configuration, socket open/close, send, receive, and socket status checks.
Network configuration: MAC address, static IP or DHCP policy, subnet mask, gateway, DNS if needed, and link-state diagnostics.
TCP server layer: open a listening socket, accept a Modbus TCP client, receive requests, send responses, and clean up disconnected sockets.
Modbus application layer: parse the MBAP header, check function code, map address ranges to registers/coils, validate length, and build response or exception frames.
Recovery layer: timeout handling, socket close/reopen, W5500 reset on persistent failure, and watchdog integration.
The official WIZnet ioLibrary is relevant for this kind of firmware because it is designed for WIZnet TCP/IP chips including W5500 and provides Berkeley Socket type APIs. This allows firmware to be structured around socket operations rather than raw Ethernet frame handling.
Conceptual integration example based on WIZnet ioLibrary:
/* Conceptual integration example based on WIZnet ioLibrary */
board_clock_init();
spi_init_for_w5500();
w5500_reset();
wizchip_spi_register_callbacks();
wizchip_init(tx_rx_buffer_config);
network_configure_static_ip_or_dhcp();
socket(SOCK_MODBUS, Sn_MR_TCP, 502, 0);
listen(SOCK_MODBUS);
while (1) {
if (client_connected(SOCK_MODBUS)) {
int len = recv(SOCK_MODBUS, rx_buf, sizeof(rx_buf));
if (len > 0) {
int rsp_len = modbus_handle_request(rx_buf, len, tx_buf);
if (rsp_len > 0) {
send(SOCK_MODBUS, tx_buf, rsp_len);
}
}
}
handle_socket_timeout();
handle_link_diagnostics();
feed_watchdog();
}
Modbus itself is an application-layer messaging protocol using a client/server model. The Modbus specification states that Modbus is positioned at OSI layer 7 and that Modbus can be accessed on the reserved system port 502 over TCP/IP. This makes port 502 the natural default for a Modbus TCP server, although a Maker test setup may use a different port if the test tool and firmware both agree.
6. Practical Tips / Pitfalls
Start with static IP for Maker testing. DHCP is convenient, but a static IP makes early Modbus TCP testing easier because the PC-side Modbus client always knows where to connect.
Keep the TCP server single-client first. W5500 supports eight sockets, but a Maker firmware project should first validate one Modbus TCP client, one socket, and one register map before adding multiple clients.
Separate socket state from Modbus state. A TCP disconnect should not corrupt the Modbus register map. Keep connection handling and application register storage in separate modules.
Validate Modbus frame length. Do not assume every received TCP payload is a complete and valid Modbus request. Check MBAP length, unit identifier, function code, address, and quantity before building a response.
Use UART logs during bring-up. Print W5500 detection status, IP address, socket state, client connection state, request length, and Modbus function code. These logs make Maker debugging much faster.
Add socket cleanup. If the client disconnects, the cable is removed, or the socket enters an unexpected state, close and reopen the socket deliberately instead of waiting for the whole board to be reset.
Respect buffer limits. Modbus TCP frames are usually small, but the firmware should still use fixed-size buffers and reject oversized frames cleanly.
7. FAQ
Why use WIZnet W5500 for this project?
W5500 is suitable because the project needs wired Ethernet and TCP server behavior on an STM32F4-class MCU. W5500 provides a hardwired TCP/IP stack, integrated 10/100 Ethernet MAC/PHY, eight sockets, and internal Tx/Rx buffers, so the firmware can focus on Modbus logic and device behavior.
How does W5500 connect to the platform?
W5500 connects to STM32F4 through SPI, with additional chip-select and reset control lines. The MCU firmware must initialize SPI, control W5500 reset, configure network parameters, and then use socket operations for TCP communication. WIZnet documentation identifies SPI as the host interface and describes W5500 as an external MCU-connected Ethernet controller.
What role does W5500 play in this project?
W5500 provides the Ethernet transport and TCP/IP offload layer. STM32F4 handles board firmware, Modbus parsing, register mapping, and device I/O. W5500 handles Ethernet MAC/PHY behavior, TCP socket state, and packet buffering.
Can beginners follow this project?
Yes, especially as a Maker project, because the system can be tested step by step: first SPI detection, then IP configuration, then TCP server listening, then Modbus request parsing, and finally real I/O mapping. Beginners should avoid adding multiple sockets, DHCP fallback, and advanced diagnostics until the single-client path is stable.
What should be tested first?
Test W5500 detection first, then link status, then IP address, then TCP connection from a PC, then a simple echo response, then Modbus function parsing. Jumping directly into full Modbus behavior before verifying the socket path makes debugging harder.
8. Source
Original GitCode project page: the project is listed as a STM32F4 + W5500 TCP server + standard Modbus communication resource package for stable data transmission between a microcontroller and a Modbus client.
Official WIZnet W5500 documentation and product page: used for W5500 hardwired TCP/IP stack, SPI interface, 10/100 Ethernet MAC/PHY, supported protocols, eight sockets, 32 KB internal Tx/Rx buffer memory, and W5500 constraints.
Official WIZnet ioLibrary Driver repository: used as the firmware reference for WIZnet TCP/IP chip application design and Berkeley Socket type APIs.
Official Modbus specification sources: used for Modbus application-layer client/server behavior and the reserved TCP/IP port 502 context.
License status: the indexed GitCode content did not expose a clear license for the specific project page during verification, so the license is not claimed here.
Editorial workflow and source-handling rules followed the uploaded WIZnet UCC Curator Handover Notes.
9. Tags
WIZnet, W5500, STM32F4, Modbus TCP, TCP Server, Firmware, SPI, Ethernet, Maker, Embedded Systems, ioLibrary, Socket Programming
1. 제목
STM32F4에서 WIZnet W5500을 사용해 Maker용 Modbus TCP Server를 구축하는 방법
2. 요약
이 글은 STM32F4, WIZnet W5500, TCP server 동작, 표준 Modbus 통신을 기반으로 한 firmware 중심 Maker project를 설명한다. GitCode project는 STM32F4 + W5500 TCP server 통신과 표준 Modbus를 bring-up하기 위한 resource package로 설명되며, microcontroller가 Ethernet을 통해 Modbus client와 안정적으로 통신하도록 돕는 것을 목표로 한다. 이 architecture에서 STM32F4는 application firmware와 Modbus logic을 실행하고, W5500은 wired Ethernet interface, hardwired TCP/IP stack, socket engine, MAC/PHY, packet buffering을 제공한다.
3. 프로젝트가 하는 일
GitCode project page는 이 project를 STM32F4 W5500 TCP server / standard Modbus communication resource package로 소개한다. 설명에 따르면 이 project는 사용자가 network communication function을 구축하고, microcontroller와 Modbus client 사이에서 stable data transmission을 구현할 수 있도록 돕는다. 또한 W5500 같은 network module이 장착된 STM32 microcontroller에 적합하다고 설명한다.
Firmware level에서 이 project는 wired Modbus TCP server design으로 이해할 수 있다. STM32F4 firmware는 board peripheral을 초기화하고, SPI를 통해 W5500을 설정하며, TCP server socket을 열고, Modbus client connection을 기다린다. 이후 Modbus request를 수신하고, 해당 request를 local data 또는 device state에 mapping한 뒤, Modbus response를 반환한다. W5500은 Ethernet transport layer를 처리하고, STM32F4 firmware는 application behavior를 처리한다.
Maker project 관점에서 이 구조는 embedded I/O와 PC-side 또는 HMI-side Modbus tool 사이를 연결하는 실용적인 bridge가 된다. 사용자는 sensor, relay, GPIO, ADC channel 또는 simulated register value를 STM32F4에 연결하고, 이를 Modbus register 또는 coil로 노출한 뒤, wired Ethernet을 통해 Modbus TCP client에서 device를 테스트할 수 있다.
예상 data flow는 다음과 같다.
STM32F4 local I/O 또는 test data → firmware register map → Modbus TCP response → W5500 TCP socket → Ethernet client.
반대 방향은 다음과 같다.
Modbus TCP request → W5500 receive buffer → STM32F4 socket read → Modbus parser → application state update.
4. WIZnet이 들어가는 위치
이 architecture에서 사용하는 WIZnet 제품은 W5500이다. WIZnet은 W5500을 SPI를 통해 외부 MCU와 연결되는 hardwired TCP/IP Internet controller로 설명한다. W5500은 최대 80 MHz high-speed SPI를 지원하고, 10/100 Ethernet MAC과 PHY를 통합하며, TCP, UDP, ICMP, IPv4, ARP, IGMP, PPPoE를 지원한다. 또한 8개의 independent socket과 Tx/Rx buffer용 32 KB internal memory를 제공한다.
이 project에서 W5500은 단순한 physical Ethernet adapter가 아니다. W5500은 network offload boundary이다. STM32F4 firmware는 application code에서 전체 TCP/IP stack을 구현할 필요가 없다. 대신 W5500을 설정하고, socket을 열고, byte를 송수신하며, Modbus request handling에 집중한다.
이 역할 분리는 Maker firmware에 특히 유용하다. 사용자는 system을 다음 세 layer로 나눠 이해할 수 있다.
STM32F4 board firmware와 peripheral logic.
W5500 Ethernet 및 socket transport.
Modbus TCP request/response protocol.
W5500은 firmware가 반드시 고려해야 하는 practical constraint도 제공한다. 8-socket limit은 허용할 client 수를 project에서 정의해야 한다는 뜻이다. 32 KB internal Tx/Rx buffer memory는 firmware가 unbounded transfer를 피하고 Modbus frame handling을 deterministic하게 유지해야 한다는 뜻이다. 또한 W5500 product page는 W5500이 IP fragmentation을 지원하지 않는다고 설명하므로, firmware는 application behavior에서 fragmented IP packet에 의존하지 않는 것이 좋다.
5. 구현 참고 사항
GitCode page는 project topic과 W5500 사용을 확인해 주지만, visible indexed content에서는 complete source file이나 detailed implementation code가 노출되지 않았다. 따라서 이 section은 repository의 정확한 file path, function name, code snippet을 주장하지 않는다. 대신 verified project description과 공식 WIZnet reference에 맞는 firmware-level integration outline을 제공한다.
실용적인 STM32F4 + W5500 + Modbus TCP firmware는 다음 module로 나눌 수 있다.
Board bring-up: system clock, GPIO, SPI, chip-select pin, reset pin, UART debug output, optional LED indicator.
W5500 driver layer: SPI read/write callback, W5500 reset sequence, network parameter configuration, socket open/close, send, receive, socket status check.
Network configuration: MAC address, static IP 또는 DHCP policy, subnet mask, gateway, 필요 시 DNS, link-state diagnostics.
TCP server layer: listening socket open, Modbus TCP client accept, request receive, response send, disconnected socket cleanup.
Modbus application layer: MBAP header parsing, function code check, address range를 register/coil에 mapping, length validation, response 또는 exception frame 생성.
Recovery layer: timeout handling, socket close/reopen, persistent failure 시 W5500 reset, watchdog integration.
공식 WIZnet ioLibrary는 이런 종류의 firmware에 적합하다. W5500을 포함한 WIZnet TCP/IP chip을 대상으로 설계되어 있고, Berkeley Socket type API를 제공하기 때문이다. 이를 통해 firmware는 raw Ethernet frame handling이 아니라 socket operation 중심으로 구성될 수 있다.
Conceptual integration example based on WIZnet ioLibrary:
/* Conceptual integration example based on WIZnet ioLibrary */
board_clock_init();
spi_init_for_w5500();
w5500_reset();
wizchip_spi_register_callbacks();
wizchip_init(tx_rx_buffer_config);
network_configure_static_ip_or_dhcp();
socket(SOCK_MODBUS, Sn_MR_TCP, 502, 0);
listen(SOCK_MODBUS);
while (1) {
if (client_connected(SOCK_MODBUS)) {
int len = recv(SOCK_MODBUS, rx_buf, sizeof(rx_buf));
if (len > 0) {
int rsp_len = modbus_handle_request(rx_buf, len, tx_buf);
if (rsp_len > 0) {
send(SOCK_MODBUS, tx_buf, rsp_len);
}
}
}
handle_socket_timeout();
handle_link_diagnostics();
feed_watchdog();
}
Modbus는 client/server model을 사용하는 application-layer messaging protocol이다. Modbus specification은 Modbus가 OSI layer 7에 위치하며, TCP/IP에서는 reserved system port 502를 통해 접근할 수 있다고 설명한다. 따라서 port 502는 Modbus TCP server의 자연스러운 default port이다. 다만 Maker test setup에서는 test tool과 firmware가 모두 동의한다면 다른 port를 사용할 수도 있다.
6. 실용 팁 / 주의점
Maker test는 static IP로 시작한다. DHCP는 편리하지만, static IP를 사용하면 PC-side Modbus client가 항상 동일한 주소로 접속할 수 있어 초기 Modbus TCP testing이 쉬워진다.
TCP server는 single-client부터 검증한다. W5500은 8개의 socket을 지원하지만, Maker firmware project에서는 먼저 Modbus TCP client 1개, socket 1개, register map 1개를 안정화한 뒤 multiple client를 추가하는 것이 좋다.
Socket state와 Modbus state를 분리한다. TCP disconnect가 Modbus register map을 손상시키면 안 된다. Connection handling과 application register storage는 별도의 module로 유지하는 것이 좋다.
Modbus frame length를 검증한다. 수신된 모든 TCP payload가 완전하고 유효한 Modbus request라고 가정하면 안 된다. Response를 만들기 전에 MBAP length, unit identifier, function code, address, quantity를 확인해야 한다.
Bring-up 중에는 UART log를 사용한다. W5500 detection status, IP address, socket state, client connection state, request length, Modbus function code를 출력하면 Maker debugging이 훨씬 쉬워진다.
Socket cleanup을 추가한다. Client가 disconnect되거나, cable이 제거되거나, socket이 예상하지 못한 state에 들어가면 전체 board reset을 기다리지 말고 의도적으로 socket을 close/reopen해야 한다.
Buffer limit을 지킨다. Modbus TCP frame은 일반적으로 작지만, firmware는 fixed-size buffer를 사용하고 oversized frame을 clean하게 reject해야 한다.
7. FAQ
왜 이 프로젝트에 WIZnet W5500을 사용하나?
W5500은 STM32F4급 MCU에서 wired Ethernet과 TCP server behavior가 필요한 project에 적합하다. W5500은 hardwired TCP/IP stack, integrated 10/100 Ethernet MAC/PHY, 8개의 socket, internal Tx/Rx buffer를 제공하므로, firmware는 Modbus logic과 device behavior에 집중할 수 있다.
W5500은 platform과 어떻게 연결되나?
W5500은 SPI를 통해 STM32F4에 연결되며, 추가로 chip-select와 reset control line이 필요하다. MCU firmware는 SPI를 초기화하고, W5500 reset을 제어하며, network parameter를 설정한 뒤, socket operation을 사용해 TCP communication을 수행해야 한다. WIZnet documentation은 SPI를 host interface로 설명하고, W5500을 external MCU-connected Ethernet controller로 설명한다.
이 프로젝트에서 W5500의 역할은 무엇인가?
W5500은 Ethernet transport와 TCP/IP offload layer를 제공한다. STM32F4는 board firmware, Modbus parsing, register mapping, device I/O를 처리한다. W5500은 Ethernet MAC/PHY behavior, TCP socket state, packet buffering을 처리한다.
초보자도 이 project를 따라 할 수 있나?
가능하다. 특히 Maker project로 적합하다. System을 단계별로 테스트할 수 있기 때문이다. 먼저 SPI detection, 그다음 IP configuration, TCP server listening, Modbus request parsing, 마지막으로 real I/O mapping을 검증하면 된다. 초보자는 single-client path가 안정화되기 전까지 multiple socket, DHCP fallback, advanced diagnostics를 추가하지 않는 것이 좋다.
무엇을 먼저 테스트해야 하나?
먼저 W5500 detection을 테스트하고, 그다음 link status, IP address, PC에서의 TCP connection, simple echo response, Modbus function parsing 순서로 검증하는 것이 좋다. Socket path를 확인하기 전에 full Modbus behavior로 바로 넘어가면 debugging이 어려워진다.
8. 출처
Original GitCode project page:
이 project는 STM32F4 + W5500 TCP server + standard Modbus communication resource package로 소개되며, microcontroller와 Modbus client 사이의 stable data transmission을 위한 자료로 설명된다.
Official WIZnet W5500 documentation and product page:
W5500 hardwired TCP/IP stack, SPI interface, 10/100 Ethernet MAC/PHY, supported protocols, 8 sockets, 32 KB internal Tx/Rx buffer memory, W5500 constraint 확인에 사용했다.
Official WIZnet ioLibrary Driver repository:
WIZnet TCP/IP chip application design과 Berkeley Socket type API를 위한 firmware reference로 사용했다.
Official Modbus specification sources:
Modbus application-layer client/server behavior와 reserved TCP/IP port 502 context 확인에 사용했다.
License status:
검증 과정에서 indexed GitCode content는 해당 project page의 명확한 license를 노출하지 않았으므로, license는 주장하지 않는다.
Editorial workflow와 source-handling rule은 업로드된 WIZnet UCC Curator Handover Notes를 따랐다.
9. 태그
WIZnet, W5500, STM32F4, Modbus TCP, TCP Server, Firmware, SPI, Ethernet, Maker, Embedded Systems, ioLibrary, Socket Programming