Quick Answer
An IoT Gateway Design for connecting sensors to the cloud with STM32 provides a complete hardware and firmware architecture for industrial IoT applications. The gateway bridges local field devices (sensors, actuators, PLCs) communicating via Modbus RTU, CAN bus, and analog signals to cloud platforms via MQTT, HTTP REST, or OPC-UA over Ethernet or cellular (4G/LTE). At InnovChip, our standard IoT gateway design uses the STM32F407 or STM32H743 depending on performance requirements, with support for up to 64 field devices, 256 MQTT topics, and secure OTA firmware updates.
https://innovchip.net/wp-content/uploads/2026/06/pexels_221185-6.jpg
What Is an IoT Gateway and Why Do You Need One?
An IoT gateway sits at the edge of the network — between physical devices in the field and cloud applications in the data center. Its role is threefold: protocol translation (converting field-level protocols like Modbus RTU and CAN bus into cloud-level protocols like MQTT and HTTPS), data processing (filtering, aggregating, and enriching raw sensor data before transmission to the cloud), and security (encrypting data in transit, authenticating devices, and managing access control at the network boundary).
In industrial environments, IoT gateways are essential because most field devices speak protocols that cloud platforms do not understand natively. A temperature sensor outputs a 4-20mA current loop. A VFD communicates via Modbus RTU over RS-485. A PLC uses CAN bus for inter-device messaging. None of these can connect directly to AWS IoT Core or Azure IoT Hub. The IoT gateway performs the necessary protocol conversion, data formatting, and security functions to make this connection seamless.
At InnovChip Electronics, we have designed and manufactured custom IoT gateways for over 30 clients across manufacturing, energy, water treatment, agriculture, and smart building applications. Our gateway designs range from simple single-port devices (1x Modbus RTU to MQTT) to complex multi-protocol gateways (4x RS-485 + 2x CAN + 8x analog inputs + Ethernet + 4G cellular + WiFi + Bluetooth).
STM32-Based Hardware Architecture
We offer two standard MCU platforms for IoT gateway designs, selected based on the application’s performance and interface requirements.
Standard Platform: STM32F407VGT6. 168 MHz Cortex-M4F, 1MB flash, 192KB SRAM, 3 USARTs + 2 UARTs, 3 SPI, 2 I2C, 2 CAN, USB 2.0 OTG, Ethernet MAC (10/100 Mbps). Suitable for gateways with up to 4 serial ports, 2 CAN interfaces, and moderate data processing requirements. The hardware floating-point unit accelerates Modbus CRC computation and data scaling operations. The 192KB SRAM supports a FreeRTOS configuration with 8-12 tasks, TCP/IP stack (LwIP), and MQTT client simultaneously. This platform is used in approximately 70% of our gateway projects.
High-Performance Platform: STM32H743VIT6. 480 MHz Cortex-M7, 1MB flash, 1MB SRAM (split between TCM and AXI SRAM), same peripheral set as F4 plus additional high-speed interfaces. Selected when the gateway needs to perform edge computing tasks (data aggregation with 100+ variables, running local machine learning inference, complex protocol conversions) or when higher throughput is required (multiple Ethernet interfaces, high-speed CAN-FD at 5 Mbps). The 1MB SRAM eliminates the need for external SDRAM in most applications.
Common peripheral interfaces on our gateway boards: 4x isolated RS-485 (ADM2587E, 2500Vrms isolation, for Modbus RTU and other serial protocols), 2x CAN bus (TJA1050 or ISO1050 isolated CAN transceiver), 8x analog inputs (12-bit or 16-bit ADC with 4-20mA and 0-10V input ranges), 8x digital inputs (24V isolated, for switch/relay monitoring), 4x digital outputs (relay or open-collector, 24V/2A), 1x Ethernet 10/100 Mbps (LAN8720A PHY, RJ45 with integrated magnetics), 1x USB Type-C (for configuration and firmware updates), 1x MicroSD card (for data logging and firmware images), 1x RTC with coin-cell backup battery, and 1x hardware watchdog (MAX6370, 1.6-6.3V, adjustable timeout 1ms to 1min).
Power Supply Design for Industrial Reliability
Industrial IoT gateways must operate reliably from a wide-input power supply. Our standard design accepts 9-36V DC (covering 12V, 24V, and 48V nominal industrial supplies) with the following protection chain: reverse polarity protection (P-channel MOSFET, no fuse in the current path for minimum voltage drop), EMI filter (common-mode choke + X and Y capacitors for conducted emissions compliance), overvoltage protection (TVS diode, 40V clamping voltage), and input undervoltage lockout (comparator circuit prevents operation below 8V, avoiding brown-out brown-out behavior).
The main power rail is generated by a TPS54331 buck converter (3.5A output, 5V, 570 kHz switching frequency, 90% efficiency at 12V input). A secondary 3.3V rail for the MCU and logic is provided by the STM32’s internal regulator or an external LDO (TPS7A4700, ultra-low noise 4μVrms). The isolated RS-485 sections each have their own isolated DC-DC converters (MAX5087, 5V output, 1W). Total power consumption of a typical 4-port gateway: 2.5W (STM32 + peripherals + 4 RS-485 drivers + Ethernet PHY). With 24V input at 2.5W, the input current is approximately 104mA — well within the capabilities of standard 24V industrial power supplies.
Communication Protocol Stack
The gateway firmware implements a modular protocol stack where each protocol runs as an independent FreeRTOS task. The standard configuration includes: Modbus RTU master (polling up to 64 slave devices per port), Modbus TCP slave (server on TCP port 502, up to 10 simultaneous connections), MQTT client (TLS 1.2 encrypted, QoS 0/1/2, configurable keep-alive and reconnect strategy), HTTP REST client (for cloud APIs that do not support MQTT, with JSON payload serialization), and OPC-UA client (for manufacturing IT/OT convergence, using the open62541 stack).
The data broker is the central component that connects all protocol tasks. It maintains a tag database (configurable, typically 200-1000 tags) where each tag has a symbolic name, data type, engineering unit, current value, quality indicator, and timestamp. Any protocol task can read or write any tag — the broker handles data type conversion, scaling (e.g., raw register value 1234 scaled by 0.01 to 12.34 kW), and timestamp management. When a value changes on any tag, the broker evaluates any configured rules (threshold comparison, rate-of-change detection) and triggers the appropriate actions (alarm notification via MQTT, email via SMTP, or local relay activation).
Edge Computing Capabilities
Modern IoT gateways are not just protocol converters — they perform meaningful data processing at the edge, reducing cloud bandwidth requirements and enabling sub-second response to local events. Our gateway firmware includes three levels of edge computing: Data aggregation — computing averages, minimums, maximums, and standard deviations over configurable time windows (e.g., “average temperature over the last 5 minutes” computed every 5 seconds). Data filtering — applying moving-average filters, dead-band filters (only report when value changes by more than a configurable delta), and outlier detection (report values outside 3-sigma range as anomalies). Local automation — executing simple if-then-else rules that trigger outputs based on input conditions (e.g., “if tank level > 90% AND pump is OFF, turn pump ON”) without requiring cloud connectivity.
For more advanced edge computing (machine learning inference, complex analytics), we offer the STM32H743 platform with X-CUBE-AI (ST’s TensorFlow Lite Micro integration). This enables running lightweight neural network models directly on the gateway — for example, a vibration anomaly detection model that classifies accelerometer data into “normal,” “warning,” or “alarm” states with sub-10ms inference time.
Security Architecture
Security is built into our gateway design from the hardware level up, following the NIST IoT device cybersecurity guidelines (NISTIR 8259) and IEC 62443 industrial cybersecurity standards. Hardware security: The STM32F4/H7’s option bytes configure read-out protection (RDP level 1 or 2) to prevent firmware extraction. For production deployments with higher security requirements, we use the ATECC608A secure element (Microchip) for hardware key storage, ECDSA signature generation, and AES-256 encryption — the cryptographic keys never leave the secure element, eliminating the risk of key extraction even if the MCU is compromised.
Communication security: All cloud communication uses TLS 1.2 or 1.3 with mutual authentication (X.509 certificates). For MQTT, we use TLS with server authentication and optional client certificates. For Modbus RTU/TCP, we implement user authentication and access control at the gateway level (password-protected configuration, role-based access control for tag read/write permissions). Firmware security: Secure Boot verifies the firmware image at every startup using ECDSA-P256 signatures. OTA firmware updates are signed and verified before installation, with automatic rollback to the previous version if the new firmware fails a self-test within 30 minutes of application.
OTA Firmware Update System
Field-deployed IoT gateways need reliable over-the-air firmware update capability. Our OTA system uses a dual-bank approach: the flash memory is split into two banks — Bank A runs the current firmware, Bank B receives the new firmware image. The update process: (1) The gateway downloads the firmware image from the cloud (MQTT or HTTPS, TLS encrypted). (2) The downloaded image is verified using SHA-256 hash and ECDSA-P256 signature. (3) The bootloader swaps the active bank and resets the MCU. (4) The new firmware starts a self-test routine and sends a “firmware OK” message to the cloud. (5) If no “OK” message is received within 30 minutes, the bootloader automatically rolls back to Bank A.
This approach provides zero-downtime updates with automatic rollback capability. In our deployments across 500+ gateway units over 3 years, we have never experienced a permanently bricked device due to a failed OTA update. The firmware images are typically 200-500KB, which download in 2-5 seconds over Ethernet or 10-30 seconds over 4G cellular. We recommend OTA updates during scheduled maintenance windows (typically monthly) with advance notification to operators.
Cloud Integration Options
We have integrated our IoT gateways with the following cloud platforms: AWS IoT Core — MQTT with TLS mutual authentication, Thing shadows for state synchronization, Rules Engine for data routing to DynamoDB/S3/Kinesis, and FreeRTOS OTA for managed firmware updates. Azure IoT Hub — MQTT with SAS token or X.509 authentication, Device Twins for state management, IoT Edge for containerized edge computing, and Azure IoT Hub Device Update for OTA. ThingsBoard (Community and Professional editions) — MQTT with access token authentication, rich dashboard widgets, alarm rules engine, and RPC (Remote Procedure Call) for bidirectional device control. Custom MQTT brokers — Mosquitto, EMQX, or HiveMQ for clients who operate their own infrastructure. We also support HTTP REST integration with custom APIs for legacy systems that do not support MQTT.
Engineer’s Notes: Lessons from 200+ Gateway Deployments
When designing IoT gateways for industrial environments, the most reliable investment is in the power supply, not the MCU. We have seen more gateway failures caused by power supply issues (surges, brownouts, ground loops) than by firmware bugs or hardware failures. The $2-3 invested in proper input protection (TVS diode, reverse polarity MOSFET, input filter) pays for itself many times over in reduced field failures. Similarly, isolated RS-485 transceivers cost $1-2 more than non-isolated alternatives, but they prevent the ground loop failures that are the single most common cause of serial communication problems in industrial installations.
Another lesson: always design for offline operation. Cloud connectivity is not 100% reliable — industrial networks go down, cellular signal drops, and cloud services experience outages. Every IoT gateway we build must continue its local Modbus polling, data logging, and alarm monitoring functions even when the cloud connection is lost. The data logging buffer should hold at least 24-48 hours of data at normal polling rates, stored in flash or eMMC. When connectivity is restored, the gateway should automatically upload the buffered data with original timestamps. This “store and forward” capability has prevented data loss in every connectivity outage we have encountered in 3+ years of field operation.
Frequently Asked Questions
What is the difference between your IoT gateway and a commercial product like Siemens IOT2050 or Advantech UNO-2271G?
Commercial industrial IoT gateways (Siemens, Advantech, Dell Edge Gateway) are general-purpose devices running Linux on ARM Cortex-A processors. They offer maximum flexibility and computing power but at a higher cost ($300-800 per unit) and with higher power consumption (5-15W). Our STM32-based gateways are application-specific — designed for a particular set of protocols, data flows, and I/O requirements. This specialization allows us to deliver a gateway at $50-150 per unit (depending on configuration) with power consumption under 3W, no Linux maintenance overhead, and no software licensing fees. For applications that need edge computing with Docker containers, Node-RED, or Python scripts, the commercial Linux-based gateways are the better choice. For applications that need reliable Modbus-to-MQTT bridging with 10+ years of maintenance-free operation, our STM32-based design is superior.
Can the gateway handle high-frequency data (e.g., vibration at 10 kSPS)?
For high-frequency data acquisition, we offer the STM32H743 platform with external ADCs (ADS8686, 500 kSPS, 16-bit) and dedicated SDRAM for data buffering. This variant can capture up to 4 channels at 500 kSPS simultaneously, performing real-time FFT and feature extraction before transmitting compressed results to the cloud. However, if your application requires continuous streaming of raw high-frequency data (not just features), the bandwidth requirements typically exceed what is practical for IoT cloud connectivity — a 4-channel 500 kSPS stream generates 4 MB/s, which requires dedicated Ethernet or local storage rather than MQTT.
Do you provide ongoing firmware maintenance and support?
Yes. Our standard delivery includes 12 months of firmware warranty covering bug fixes and compatibility updates. Optional maintenance contracts are available for ongoing support: quarterly firmware releases with feature updates, security patches, and compatibility updates for new cloud platform versions; priority support with 4-hour response time during business hours; annual on-site review of gateway performance and recommendations for optimization. Approximately 60% of our gateway clients continue with maintenance contracts after the warranty period.
What certifications does the gateway hardware meet?
Our standard gateway PCB and enclosure are designed for CE (EN 61000-6-2/6-4 EMC), FCC Part 15 Class A, and RoHS compliance. For clients requiring formal certification, we provide pre-compliance test data and coordinate with accredited test labs (SGS, TÜV, Intertek) for certification testing. Typical certifications requested: CE marking (mandatory for EU), FCC (mandatory for US), UL/cUL (optional for North American industrial environments), and ATEX/IECEx (for hazardous area installations, requiring intrinsically safe or explosion-proof enclosure variants). Certification timeline: 4-8 weeks from submission to approval, with costs ranging from $2,000 (CE only) to $15,000+ (ATEX with explosion-proof enclosure).
Need a custom IoT gateway for your project? Contact InnovChip Electronics for a free requirements assessment, architecture proposal, and competitive quote. We have delivered 200+ IoT gateway projects for clients in 30+ countries.