Industrial Modbus gateway

Industrial Modbus Gateway with WIZnet W5500

Project Overview

Many industrial devices, including environmental sensors, power meters, and PLCs, still rely on RS-485-based Modbus RTU communication. Connecting these devices to Ethernet networks requires a gateway capable of converting Modbus RTU messages into Modbus TCP.

This project implements an industrial Modbus RTU-to-TCP gateway using the STM32F103C8T6 microcontroller and WIZnet W5500 Ethernet controller.

Beyond basic protocol conversion, it incorporates multi-client request management, RS-485 fault detection, automatic firmware rollback, persistent event logging, and centralized monitoring.

The system consists of two main components:

STM32 + W5500 Gateway: Runs FreeRTOS and handles Modbus conversion, Ethernet communication, fault detection, and OTA firmware updates.

Linux Monitoring Server: Collects data from multiple gateways and provides SQLite storage, a web dashboard, REST APIs, and alarm management.

The Linux server is optional. The STM32 and W5500 gateway can operate independently as a Modbus RTU-to-TCP converter.

The project's primary value lies in combining Modbus communication with reliability, fault recovery, and maintenance features designed for long-term operation.

Key Features

1. Multi-Client Modbus TCP Gateway

The WIZnet W5500 provides a hardware TCP/IP stack, reducing the networking workload on the STM32 microcontroller.

The project uses four W5500 TCP sockets, configured on ports 502–505, to process Modbus TCP requests.

However, multiple TCP clients sharing a single half-duplex RS-485 bus must coordinate their requests to prevent overlapping RTU transactions.

The implementation uses:

A socket state machine for non-blocking request management

• g_rtu_busy : to prevent overlapping RTU transactions
• g_buf_mutex : to protect shared communication buffers
• g_modbus_mutex : to coordinate RS-485 bus access

These mechanisms help prevent communication conflicts when multiple Ethernet clients access devices connected to the same RS-485 interface.

Key takeaway: The project demonstrates how to coordinate multiple W5500 TCP connections over a shared RS-485 communication channel.

2. W5500 SPI Addressing and Debugging

Another interesting aspect is the project's documentation of a W5500 SPI memory block addressing issue encountered during development.

The W5500 uses Block Select Bits (BSB) to distinguish socket registers from TX and RX memory buffers.

The project uses the following block address calculations:

SOCK_REG(n) = 1 + 4 * n
TX_BLOCK(n) = 2 + 4 * n
RX_BLOCK(n) = 3 + 4 * n

Incorrect block selection can result in unintended register or memory access, even when SPI communication appears to be functioning.

This example provides practical insight into W5500 memory architecture, low-level driver development, and hardware debugging.

3. OTA Firmware Updates with Automatic Rollback

The gateway uses an external W25Q64 Flash memory and a dedicated bootloader to support firmware updates over Ethernet.

A particularly notable feature is its automatic rollback mechanism, designed to restore the previous firmware if an updated application repeatedly fails to boot.

The update procedure includes:

• Backing up the existing firmware to external Flash
• Receiving the new firmware and verifying its integrity using CRC32
• Installing and booting the updated application
• Restoring the previous firmware after repeated boot failures

How does this differ from WIZnet WIZ750SR?

WIZnet's WIZ750SR already supports network firmware updates and application recovery through its AppBoot mechanism.

However, the official WIZ750SR firmware history indicates that the application backup area has not been used since version 1.2.0.

In contrast, this project explicitly implements previous-firmware backup and automatic restoration based on boot failure detection.

The distinction is therefore not remote firmware updating itself, but the implementation of automatic rollback to a previously working application.

4. Fault Detection and Persistent Event Logging

Reliable industrial gateways require mechanisms for detecting failures and identifying their causes.

This project incorporates:

• Periodic RS-485 communication health checks at 60-second intervals
• Heartbeat monitoring for individual FreeRTOS tasks
• Software watchdog supervision and hardware IWDG
• Persistent storage for up to 2,048 event records in external Flash
• Logging of TCP connections, RS-485 errors, restarts, and configuration changes

Event records are written asynchronously through a message queue to reduce interference with communication tasks.

These features demonstrate how fault detection, recovery supervision, and persistent diagnostics can be integrated into a W5500-based embedded gateway.

5. Linux-Based Multi-Gateway Monitoring

The optional Linux monitoring server is designed to collect data from up to 16 Modbus gateways.

It uses Linux epoll and timerfd to manage multiple TCP connections and periodic data collection.

Key capabilities include:

• Modbus TCP data acquisition
• SQLite-based historical data storage
• Temperature and humidity trend visualization
• Threshold-based alarms
• REST API and web dashboard
• Remote firmware update management

The Linux server also supports runtime configuration reloading through SIGHUP, allowing gateway polling parameters to be updated without restarting the monitoring process.

Because the monitoring server is separate from the embedded gateway, Modbus conversion can continue independently of the Linux host.

This architecture illustrates how multiple W5500-based gateways can be integrated into a centralized monitoring system without requiring Linux on each device.

Hardware Setup

The W5500 communicates with the STM32 through SPI2, while the RS-485 interface uses USART2.

The external W25Q64 Flash connects through SPI1 and stores configuration data, firmware backups, and event logs.

Comparison with Existing WIZnet Maker Projects

Several projects on the WIZnet Maker platform already demonstrate Modbus TCP servers and Modbus RTU-to-TCP conversion using W5500-based hardware.

Therefore, basic Modbus protocol conversion is not unique to this project.

Its distinguishing characteristics are the additional reliability, debugging, and monitoring mechanisms.

Some existing Maker projects also provide additional protocols, web configuration interfaces, or monitoring dashboards.

Rather than introducing a new Modbus conversion method, this project focuses on the reliability and operational management of an Ethernet-connected industrial gateway.

Its integration of request arbitration, firmware recovery, persistent diagnostics, and Linux monitoring makes it a useful reference for developers working on industrial communication systems.

Comparison with WIZnet S2E Solutions

WIZnet Serial-to-Ethernet solutions, including the WIZ750SR, already provide serial-to-Ethernet connectivity and Modbus RTU/TCP protocol conversion.

The WIZ750SR also supports network firmware updates, AppBoot-based recovery, and network-based device configuration.

This project demonstrates additional reliability and monitoring mechanisms, but it does not provide every management feature available in WIZnet's dedicated S2E solutions.

Feature Comparison

Remote Configuration: An Important Difference

One area where the WIZ750SR offers more convenient device management is remote network configuration.

WIZnet provides a dedicated S2E Configuration Tool that allows users to discover and configure devices over Ethernet.

It supports:

Network device discovery using UDP broadcast or TCP unicast

IP address, subnet mask, gateway, and port configuration

Serial communication parameter configuration

Configuration saving, device reset, and firmware updates

The official WIZ750SR firmware history also documents the addition of a configuration web server in Boot firmware v1.4.

In comparison, this Modbus Gateway project stores network and communication parameters in external W25Q64 Flash with CRC32 validation.

However, a dedicated Ethernet-based configuration interface comparable to the WIZ750SR Configuration Tool has not been identified in the reviewed gateway implementation.

The Linux monitoring software supports configuration changes through config.ini and runtime reloading using SIGHUP, but this controls the Linux monitoring application rather than directly modifying the STM32 gateway's network or serial settings.

This distinction is important: WIZ750SR provides a more established network configuration mechanism, while this project focuses on firmware recovery, diagnostics, and centralized monitoring.

Overall, the project serves as a complementary implementation reference rather than a replacement for all WIZ750SR S2E capabilities.

Performance Results

The project author reports the following test results:

These values are reported in the project documentation and have not been independently benchmarked.

Because all clients share a single RS-485 bus, overall throughput and response latency depend on the serial communication speed and transaction scheduling.

Lessons Learned

This project highlights several practical lessons for W5500-based industrial communication development:

W5500 Socket Management: Coordinating multiple Ethernet connections over a shared RS-485 interface

Low-Level SPI Debugging: Understanding W5500 register blocks and memory addressing

Reliable Firmware Updates: Designing firmware backup and automatic rollback mechanisms

Fault Monitoring: Combining watchdog supervision with persistent event logging

System Architecture: Separating embedded gateway communication from Linux-based data monitoring

Configuration Management: Understanding the difference between persistent device settings, remote device configuration, and Linux monitoring server configuration

Future Improvements

Potential improvements include:

Remote Gateway Configuration: Adding an Ethernet-based configuration interface for IP addresses, TCP ports, and RS-485 communication parameters

Secure Firmware Updates: Implementing firmware authentication and protected update procedures

Monitoring Security: Adding HTTPS and authentication to the Linux dashboard

Multi-Client Performance: Conducting additional load and latency tests under concurrent Modbus requests

Configuration Protection: Securing configuration data stored in external Flash

Adding remote configuration would be particularly useful because it would allow operators to update gateway network and serial settings without modifying firmware or accessing the device locally.

This would complement the project's existing OTA, diagnostic, and monitoring capabilities.

Conclusion

This project demonstrates an industrial Modbus RTU-to-TCP gateway built around the WIZnet W5500 hardware TCP/IP Ethernet controller.

Its value extends beyond basic protocol conversion through the integration of multi-client request arbitration, automatic firmware rollback, persistent fault logging, and centralized Linux monitoring.

Compared with existing Maker projects and WIZnet S2E solutions, its primary contribution is not a new Modbus conversion method, but a detailed example of how reliability, diagnostics, and maintenance capabilities can be incorporated into an Ethernet-connected industrial gateway.

At the same time, the comparison highlights the importance of network configuration and device management, areas where WIZnet's established S2E solutions provide additional functionality.

For developers working with W5500-based industrial applications, the project offers practical insights into network concurrency, low-level driver debugging, firmware recovery, and multi-device monitoring.