STM32-Based Industrial IoT Gateway Development with Ethernet, CAN and RS-485

A case study illustrates the development of an industrial IoT gateway that is ruggedized to connect legacy fieldbus networks to modern cloud platforms.

The procedure for gathering data from machine systems that use CAN and sensors using RS-485 Modbus is then transmitting this information securely using Ethernet to an MQTT broker in the cloud.

The desired location for deployment of the device was a smart factory floor with pre-existing PLC and drives operating using CANopen and Modbus RTU protocols.

The main requirements for the gateway included:

• Ability to run on Ethernet, CAN, and RS-485 simultaneously
• Conversion protocols from Modbus RTU to MQTT
• Security of cloud communication
• Ability to update software in place
• Operation at the temperatures between –40°C and +85°C.

The other condition required using the device in electrical noisy environments while simultaneously isolating all fieldbus ports.

2.1 Hardware Architecture

For the purpose of the project a microcontroller based on ARM Cortex-M7 core was chosen. The STM32F767ZI operates at the frequency of 216 MHz. It also has a RAM of 2 MB and Flash memory of 512 KB.

The microcontroller was selected because of such its nice features as integrated Ethernet MAC (10/100 Mbps), two CAN 2.0B controllers and multiple USARTs which are able to support RS-485 by means of external transceivers.

The processing power of the Cortex-M7 core is sufficient enough for connecting it with TLS encryption, protocol translation and scheduling of the real-time tasks.

Being built on the experimental hardware structure it consists of three separated communication domains: Ethernet (none-isolated, but magnetic), CAN (isolation from ground, galvanic), RS-485 (also isolated from ground, galvanic).

Power supply where the voltage of 24 V DC is used is reduced in the process of buck conversion with the help of LM5164. In this case the power supply is finally down to 3.3 V DC with the help of the LDO TPS7A4700.

In order to have the complete isolation of the microcontroller from the field wiring during the project process an isolated DC-DC converter (B0505S) was used.

2.2 Software Architecture

The firmware is build using FreeRTOS v10.5, which has a pre-emptive scheduler. The specification of the firmware comprises six tasks, Task_Ethernet (for LwIP protocol stack and MQTT client), Task_CAN (for CANopen parsing), Task_RS485 (for Modbus RTU), Task_Translation (for data normalization), Task_Cloud (for data publishing), and Task_OTA (for OTA firmware updates).

For inter-task communication, both aforementioned event groups and FreeRTOS queues were employed. Mutexes were also employed to lock critical sections of code on shared resources like a SPI bus for external Flash devices and UART for RS-485 devices.

3.1 Layer Stack and Partitioning

The design of a six-layer PCB stackup consists of signal and ground layers to adhere to the requirements of high-speed Ethernet signals and the mixed-signal isolation. The stackup includes: Signal 1 (top), Ground 1 Layer, Signal 2, Power Layer, Ground 2 Layer, and Signal 3 (bottom) layer.

The board has been divided into three zones: the digital core containing STM32, SDRAM, and Flash, the isolated fieldbus zone controlling CAN and RS-485 transceivers, and the ethernet PHY zone.

The isolation barrier is clearly marked in the PCB, and no traces cross it except using digital isolators (ADuM1201 used for both UART and CAN) and isolated dc-dc converters.

3.2 Choice of Components and Circuit Design

The LAN8720A was the Ethernet PHY that was connected to STM32 via RMII. The PHY was placed adjacent to the RJ45 while the differential pairs were matched (with an impedance of 100 ohms), and the trace lengths were matched to ±5 mil.

Texas Instruments SN65HVD230 were the CAN transceivers, while Analog Devices ADM2582E served as RS-485 transceivers. All the connectors of fieldbus were fitted with protection through the use of TVS diodes (SMBJ24CA) and common-mode chokes.

3.3 EMC and Isolation

The board was designed to meet IEC 61000-4-2 (ESD), IEC 61000-4-4 (EFT), and IEC 61000-4-5 (surge). The isolation barrier provided 2.5 kV RMS isolation for 1 minute. Ground stitching vias were placed every 5 mm around the board perimeter, and the Ethernet magnetics (HanRun HR911105A) included integrated common-mode chokes. A shielded RJ45 connector was used with the shield connected to chassis ground through a 1 nF capacitor.

4.1 Ethernet Driver

The Ethernet driver was built utilizing the STM32 HAL ETH peripheral in conjunction with the LwIP TCP/IP stack (version 2.1.2). The MAC functioned at 100 Mbps full-duplex with an additional feature of hardware checksum offload.

DMA descriptors were stored in SRAM memory to prevent an issue of cache coherency and the Cortex-M7 data cache was either turned off for the Ethernet buffer area or controlled with cache maintenance techniques.

The LwIP stack was adapted to use static IP address and was capable of supporting DHCP for flexible deployment of the technology.

4.2 CAN Driver

The driver works by utilizing the STM32 bxCAN peripheral in normal mode with loopback deactivated. The bit time is set to about 500 kbps while sample time is at 87.5%.

The receive FIFO that the driver implements can receive messages by interrupt and serve them to a queue for the CANopen stack. A lightweight CANopen stack implemented on it can conduct PDO and SDO communication.

4.3 RS-485 Driver

The RS-485 driver used USART3 with DMA for both transmission and reception. The DE (Driver Enable) pin was controlled by a timer-triggered GPIO to ensure precise timing of the transmit enable signal. The Modbus RTU master was implemented using the FreeModbus stack, polling up to 16 slave devices in a round-robin fashion. Each slave was polled for holding registers at 100 ms intervals, with a 3.5-character silent interval for frame delimitation.

5.1 Modbus to MQTT

The engine for protocol transformation translated the values from Modbus registers into MQTT topics using a JSON configuration file that was saved on external Flash. For instance, the holding register having address 40001 and slave ID 5, which corresponds to the motor's temperature, was converted to the topic factory/line1/motor5/temperature.

The conversion process involved reading the raw values from the queue containing Modbus data and applying the scaling coefficient, for instance, 0.1°C/count. After normalizing the value, the processed result was sent as a JSON payload.

5.2 CAN to MQTT

The CANopen Process Data Object (PDO) was parsed in accordance with the object dictionary. Each PDO carries as much as 8 bytes of data which can be further split up into individual signals (e.g., speed, current, status).

The signals can be mapped to MQTT topics such as factory/line1/drive2/speed. This mapping can also be made flexible through the same configuration file stated, allowing field engineers to configure the gateway for different machine types without changing firmware.

6.1 Implementation of the MQTT Client

The MQTT client was built using the embedded C client from Eclipse Paho and adapted to operate on FreeRTOS as well as LwIP. The MQTT version it operated on was 3.1.1 with QoS 0 and QoS 1.

The MQTT client maintained a persistent connection to the cloud broker. In addition to having a connection maintainability mechanism, the MQTT client was provisioned with the last-will-and-testament (LWT) message. The client's keep-alive time was set to 60 seconds, and telemetry was generated at the rate of 1 Hz.

6.2 TLS/SSL Security

Secure connectivity was achieved with mbedTLS v2.16 and TLS 1.2. Two-way authentication was carried out by the gateway using an X.509 client certificate and a shared root certificate for CA.

The TLS handshake run by Cloud IoT Core was sped up due in part to the STM32 hardware crypto unit (HASH and AES peripherals), requiring less than 800 ms for the handshake.

End-to-end encryption of the MQTT payload allowed verification of the gateway's identity by the broker before the data were accepted.

6.3 Cloud Platform Integration

The gateway was linked with the AWS IoT Core, which included utilization of the MQTT broker endpoint.

Telemetry data was sent to the $aws/things/gateway-01/shadow/update and commands from the cloud were retrieved from the $aws/things/gateway-01/shadow/update/delta.

The cloud platform assisted with the corridor which presented the information in real-time and historical data analysis.

7.1 Bootloader Development

A modified bootloader took the first 128 KB of Flash space. It used CRC32 checksumming and digital signature verification to authenticate the application firmware being loaded. If the application firmware validated successfully, the bootloader called it. In the event of a failure, the bootloader waited for another update via Ethernet or UART before continuing.

7.2 Flash and Firmware Signing with Dual Bank

In a dual bank flash mode of STM32F767 microcontroller, two images of firmware are stored in two banks i.e. an active application in Bank 1 and a new firmware application with Bank 2. After using the OTA function to download the new image through HTTPS protocol, it is written in Bank 2 after a flag is set in bootloader configuration area.

When the system is rebooted next, the bootloader checks the authenticity of the image and swaps the banks.

Functional testing confirmed that all three fieldbuses could work at the same time with full load. Security tests include penetration tests of the TLS implementation and fuzzing of the MQTT parser.

The gateway was subject to a 30-day field test at a factory and maintained 99.99% uptime while processing over 10 million MQTT messages.

The use of the STM32-based industrial IoT gateway has proven that a single Cortex-M7 processor is capable of handling Ethernet, CAN, and RS-485 simultaneously and providing a secure connection to the cloud and over-the-air updates.

Among the key aspects learned were the necessity for isolation in mixed-signal industrial concepts, the role of hardware crypto acceleration in achieving TLS latency, and the need for a configurable protocol-mapping engine for shortening deployment time.

The gateway has thus successfully linked legacy industrial technologies with modern cloud systems enabling predictive maintenance and real-time analytics in smart manufacturing.