How Does HTTP-Based OTA Work on STM32 with W5500?

Register-Level TCP Behavior, SPI Design, and Reliable Firmware Upgrade via Alibaba Cloud IoT

(STM32와 W5500을 이용한 HTTP 기반 OTA는 어떻게 동작하는가?)

Summary (40–60 words)

This article explains how an STM32 microcontroller performs HTTP-based over-the-air (OTA) firmware upgrades using the WIZnet W5500 Ethernet controller and Alibaba Cloud IoT platform. By examining SPI behavior, register-level TCP operations, and firmware upgrade flow, it shows how hardware TCP/IP enables reliable, deterministic OTA in embedded systems.

1. Why OTA over Ethernet Still Matters

Remote firmware upgrade (OTA) is no longer optional in modern embedded systems.
For industrial and infrastructure devices, OTA must be:

Reliable over long runtimes

Deterministic and recoverable

Independent of RF instability

Debuggable at the driver level

Using STM32 + W5500 + HTTP OTA provides a clear, inspectable solution where:

Firmware upgrade is driven by registers and buffers, not opaque network stacks.

2. System Architecture Overview

End-to-End OTA Architecture

Key design decision:

STM32 does not implement a software TCP/IP stack

W5500 handles all TCP reliability

STM32 focuses on HTTP parsing and flash programming

3. Why HTTP Is a Practical OTA Transport

Compared to MQTT or custom protocols, HTTP offers:

Simple request/response model

Easy server-side integration

Natural file streaming behavior

Compatibility with cloud object storage

For OTA:

Firmware file = HTTP response body

TCP guarantees ordered delivery

W5500 ensures retransmission correctness

4. Role of W5500 in the OTA Process

The W5500 is responsible for:

TCP socket creation and teardown

Three-way handshake with HTTP server

Retransmission, ACK handling

RX/TX buffering

From STM32’s perspective:

OTA = sequential RX buffer reads

Network errors = socket state changes

This clear separation is critical for robust OTA.

5. Register-Level TCP Behavior During OTA

TCP Client Setup (Conceptual)

Configure common registers

MAC, IP, gateway, subnet

Allocate TX/RX buffers

Configure socket in TCP mode

Issue CONNECT command

At this point:

W5500 handles the TCP handshake internally

STM32 waits for ESTABLISHED state

HTTP Request Phase

No TCP logic exists in STM32 code.

HTTP Response / Firmware Download

This loop continues until the firmware file is fully received.

6. SPI Behavior During OTA (Why It Matters)

OTA firmware files are typically large, which stresses the SPI path.

Critical SPI Rules

CS must remain asserted for each full SPI frame

RX reads must be contiguous and efficient

DMA or block transfers are strongly preferred

In RTOS or interrupt-heavy systems:

SPI access must be serialized

OTA task must not be preempted mid-frame

Failure here causes:

Corrupted firmware images

Silent TCP stalls

Incomplete upgrades

7. Flash Programming Strategy

A safe OTA design uses:

Dedicated upgrade partition

Incremental flash writes

CRC or checksum verification

Bootloader-controlled switch-over

Typical flow:

W5500’s reliable TCP ensures that:

File integrity depends on flash logic, not network reliability

8. Performance and Latency Characteristics

Throughput

OTA throughput is determined by:

SPI speed

RX buffer size

Flash write speed

Not by TCP/IP complexity.

Latency

Latency during OTA is irrelevant as long as:

Data arrives reliably

Timeouts are handled correctly

This is why Ethernet OTA favors stability over speed.

9. Common OTA Failure Modes (And Real Causes)

❌ Download stalls midway

Cause:

RX pointer not updated

RECV command omitted

❌ HTTP request succeeds, but file is corrupted

Cause:

SPI CS timing violation

Interrupted RX read

❌ Device bricks after reboot

Cause:

Missing image verification

Incorrect flash boundary handling

Most OTA bugs are not cloud bugs.

10. Why W5500 Is Well-Suited for OTA

Hardware TCP/IP = deterministic delivery

Fixed socket model = easy state tracking

No heap fragmentation

Easy wire-level debugging

This makes W5500 a strong choice for:

Industrial controllers

Gateways

Long-life deployed devices

11. Key Takeaway

On STM32 systems, W5500 turns OTA from a networking problem into a controlled data-transfer and flash-management problem.

When register-level behavior is understood:

HTTP OTA becomes predictable

Debugging is straightforward

Reliability matches industrial requirements

FAQ (Engineer-Focused)

Q1. Does W5500 support HTTP directly?
No. HTTP parsing runs on STM32; W5500 handles TCP only.

Q2. Is HTTP OTA safe for large firmware files?
Yes, if SPI and flash handling are correct.

Q3. Where do most OTA bugs occur?
SPI timing, buffer handling, or flash logic—not TCP.

Q4. Can this work with RTOS?
Yes, but SPI access must be protected.

Q5. Why not use MQTT for OTA?
HTTP is simpler and better suited for file transfer.

Source

CNBlogs article: yangfengwu

WIZnet W5500 Datasheet

Alibaba Cloud IoT Platform documentation

Tags

W5500, STM32, OTA, HTTP Firmware Upgrade, Alibaba Cloud IoT, SPI Ethernet, TCP Register Behavior, Industrial IoT

🇰🇷 한국어 번역 (1:1 Full Translation)

STM32와 W5500을 이용한 HTTP 기반 OTA는 어떻게 동작하는가?

알리바바 클라우드 IoT와 레지스터 수준 TCP 동작 분석

요약

본 문서는 STM32 마이크로컨트롤러와 WIZnet W5500 이더넷 컨트롤러를 사용해 알리바바 클라우드 IoT 플랫폼에서 HTTP 기반 OTA(원격 펌웨어 업그레이드)를 수행하는 구조를 분석한다. SPI 동작, 레지스터 기반 TCP 처리, 플래시 업그레이드 흐름을 통해 안정적인 OTA 구현 방법을 설명한다.

1. 이더넷 OTA의 가치

OTA에서 중요한 것은
속도가 아니라 신뢰성이다.

2. 시스템 아키텍처

3. HTTP OTA 흐름

TCP 연결 → HTTP GET → 펌웨어 수신 → 플래시 기록

4. SPI와 레지스터의 중요성

CS 타이밍과
버퍼 포인터는 OTA의 생명선이다.

5. 성능 특성

처리량은 SPI와 플래시에 의해 결정되며
TCP는 문제가 되지 않는다.

6. 핵심 메시지

W5500 기반 OTA는 네트워크 문제가 아니라 데이터 처리 문제다.

태그

STM32, W5500, OTA, HTTP 업그레이드, 알리바바 클라우드 IoT, 산업용 이더넷