Industrial IoT Gateway: stm32f407-iot-gateway
STM32F407 gateway using WIZnet W5500 for Modbus-to-MQTT monitoring, offline data buffering, OTA rollback, and automatic 4G failover.
0
Components
Hardware components
WIZnet - W5500
x 1
ARM - KEIL5
x 1
Project description
Project Overview
Reliable industrial IoT systems must continue collecting data even when their network connection becomes unstable.
This project implements an industrial IoT gateway using an STM32F407 microcontroller and WIZnet W5500 Ethernet controller.
The gateway collects temperature and humidity data through Modbus RTU and publishes the measurements to an MQTT broker using the W5500's hardware TCP/IP sockets.
Unlike a basic Ethernet sensor gateway, this system also includes offline data buffering, automatic 4G failover, SD card logging, and OTA firmware rollback.
The developer provides both STM32 Standard Peripheral Library (SPL) and HAL implementations, making the project useful for developers working with different STM32 firmware environments.
Key Features
- W5500 Ethernet: Primary MQTT communication using the integrated hardware TCP/IP stack.
- Modbus RTU: RS485 sensor acquisition and real-time monitoring.
- Offline Buffering: Stores sensor records in W25Q64 Flash during network outages.
- 4G Failover: Switches live MQTT communication to the Air780E cellular module when Ethernet is unavailable.
- Data Replay: Resends buffered data with original timestamps after Ethernet recovery.
- OTA Rollback: Preserves the previous firmware and restores it if an update fails.
- Local Monitoring: Displays system status on an LCD and records data to microSD.
Hardware Architecture
The gateway uses the STM32F407 as its central controller, with the W5500 connected through SPI1.
| W5500 Signal | STM32F407 |
|---|---|
| SCLK | PA5 |
| MISO | PA6 |
| MOSI | PA7 |
| CS | PC4 |
| RESET | PC5 |
| INT | Not connected (polling) |
The main communication path is:
RS485 Sensor → STM32F407 → W5500 → Ethernet → MQTT Broker
When Ethernet becomes unavailable, live MQTT publishing can use the Air780E 4G connection while sensor records are buffered locally.
Once Ethernet connectivity returns, the gateway switches back to the W5500 and replays stored data.
Software Implementation
The firmware uses WIZnet's ioLibrary_Driver to control the W5500 through SPI.
An excerpt from w5500_bsp.c shows how SPI communication callbacks are registered:
reg_wizchip_cs_cbfunc(
bsp_cs_select, bsp_cs_deselect);
reg_wizchip_spi_cbfunc(
bsp_spi_read, bsp_spi_write);
wizchip_init(txSize, rxSize);Each of the W5500's eight sockets is configured with 2 KB transmit and 2 KB receive buffers.
The firmware also includes a W5500_CheckConfig() function that reads the controller's network registers to detect unexpected configuration loss.
MQTT communication is managed through a connection state machine with timeout and retry handling.
Five FreeRTOS tasks manage sensor acquisition, networking, storage, LCD updates, and watchdog supervision.
Performance and Testing
According to the developer's documentation, the gateway was tested on STM32F407 hardware.
| Test | Reported Result |
|---|---|
| Sensor monitoring | LCD updated every 2 seconds |
| MQTT telemetry | Data published every 5 seconds |
| Ethernet disconnection | Offline buffering activated |
| Ethernet recovery | Buffered records replayed |
| 4G backup | Automatic MQTT path switching |
| 4G hardware reset | Approximately 26 seconds to recover in one test |
| OTA update | Firmware validation and rollback implemented |
These are developer-reported results. Independent throughput benchmarks and long-duration reliability tests have not been published.
Comparison with Similar WIZnet Maker Projects
Several existing WIZnet Maker projects demonstrate W5500-based industrial networking.
| Existing Project | Main Focus | Difference in This Project |
|---|---|---|
| KONTRX Industrial Gateway | STM32F407, W5500, multi-socket HTTP/MQTT/Modbus TCP and automation | Adds an Air780E cellular backup path for live MQTT communication |
| Industrial Offline Cache Gateway | Persistent MQTT buffering and data replay strategies | Implements buffering alongside cellular failover and firmware recovery in an STM32 system |
| Porting W5500 on STM32 | Basic DHCP, TCP/UDP communication and web server | Extends Ethernet networking to Modbus acquisition, offline storage and OTA updates |
What makes this project different?
The main contribution is not a new W5500 driver, but the integration of multiple recovery mechanisms around W5500-based Ethernet connectivity.
Compared with the basic STM32 W5500 networking example, this gateway implements a more complete telemetry workflow.
Compared with KONTRX, which emphasizes simultaneous hardware sockets and local industrial automation, this project focuses on maintaining data collection and communication continuity during Ethernet failures.
The combination of W5500 Ethernet, 4G failover, persistent Flash buffering, and OTA rollback is its most notable feature.
Related WIZnet Maker Projects
Future Improvements
Future development could include TLS-secured MQTT, signed OTA firmware verification, support for multiple Modbus devices, and longer network failover and recovery tests.
Conclusion
This project demonstrates how the WIZnet W5500 can be integrated into a fault-tolerant STM32 industrial IoT gateway.
By combining hardware TCP/IP networking with offline storage, cellular backup, and firmware recovery, it provides a practical reference for developers building Ethernet-connected monitoring systems that must continue operating through network interruptions.
