Wiznet makers

Overview

Mender is an OTA (Over-the-Air) update platform widely used in embedded Linux systems.
Recently, Mender introduced the Mender MCU Client, targeting MCU environments based on Zephyr RTOS.

The official getting-started guide uses the ESP32-S3 DevKitC as a reference platform and demonstrates OTA updates over Wi-Fi.
At the same time, Mender provides a separate guide explaining how to add a W5500 Ethernet adapter to the same Zephyr-based ESP32 environment.

This curation reviews both documents together and highlights how Wi-Fi and Ethernet can be selected depending on the development and deployment stage in MCU OTA designs.

1️⃣ Mender MCU Client Getting Started (ESP32-S3)

1. Overview

Mender is an Over-the-Air (OTA) update platform originally designed for embedded Linux systems, where it is widely used to manage large fleets of devices with robust rollback and deployment control.

With the introduction of the Mender MCU Client, Mender extends the same OTA concepts to microcontroller-based systems running RTOS environments such as Zephyr.
In this context, the OTA target is no longer a full Linux root filesystem, but a firmware image stored in MCU flash memory.

The official getting-started guide focuses on the ESP32-S3 DevKitC and demonstrates how to integrate the Mender MCU Client into a Zephyr application using Wi-Fi as the network interface.

Importantly, Mender also provides a separate, officially documented guide that explains how to replace the Wi-Fi interface with a W5500 Ethernet controller in the same Zephyr-based ESP32 environment.

When these two documents are read together, they demonstrate that:

• The Mender MCU Client OTA logic is independent of the network medium
• Wi-Fi and Ethernet are interchangeable at the system level
• Network selection is a design-time decision, not an OTA application constraint

2. Position of the Mender MCU Client in the Zephyr Stack

From an architectural perspective, the Mender MCU Client is located entirely in the application layer and relies on Zephyr’s standard networking abstractions.

 

Key technical characteristics:

• The Mender MCU Client does not access network drivers directly
• All network communication uses Zephyr’s socket API
• The active network interface is determined by Zephyr routing and interface priority
• OTA logic remains unchanged regardless of whether Wi-Fi or Ethernet is used

This strict separation is what allows the same OTA implementation to operate across different network transports.

3. Wi-Fi-Based OTA on ESP32-S3

In the reference implementation, Wi-Fi is used as the default network interface.

Technical details

• Wi-Fi is provided by the ESP32 internal radio
• Zephyr creates a net_if instance bound to the Wi-Fi driver
• TCP/IP and TLS processing are handled entirely by the MCU
• OTA artifacts are downloaded via HTTPS
• Firmware is written to an inactive flash partition
• After reboot, the Mender MCU Client validates the update and commits or rolls back

Characteristics

• No external hardware required
• Fast setup and minimal configuration
• Suitable for development, evaluation, and PoC environments

Limitations

• Network quality depends on RF environment
• MCU must handle TCP/IP stack load during OTA
• Long OTA sessions are sensitive to connection instability

4. Integrating W5500 Ethernet

The W5500 guide describes how to replace the Wi-Fi interface with a SPI-connected Ethernet controller.

What changes

• Network driver changes from ESP32 Wi-Fi to W5500 Ethernet
• Zephyr device tree is updated to describe:
  • SPI bus
  • Chip select
  • Interrupt line
• Ethernet interface is registered as a new net_if

What does not change

• Mender MCU Client source code
• OTA state machine logic
• Artifact format and download mechanism
• Flash layout and rollback behavior

Technical implications

• W5500 is a hardwired TCP/IP controller
• TCP/IP processing is offloaded from the MCU
• MCU interacts with W5500 using socket-like commands over SPI
• Reduced CPU load and timing jitter during OTA

5. Wi-Fi vs W5500 Ethernet for OTA

6. Technical Q&A: Using Wi-Fi and W5500 Together

Q1. Can Wi-Fi and W5500 Ethernet be enabled at the same time in Zephyr?

Yes.
Zephyr supports multiple network interfaces (net_if) simultaneously.
Both Wi-Fi and W5500 Ethernet can be active, each with its own IP configuration.

Q2. Does the Mender MCU Client use both interfaces simultaneously during OTA?

No.
A single OTA session should use one network path only.
The interface used for OTA is selected by Zephyr routing rules and interface priority.

Q3. What is the recommended design pattern?

The recommended approach is:

• Primary OTA path: W5500 Ethernet
• Fallback path: Wi-Fi
• Disable interface switching while OTA is in progress

This minimizes TLS session interruptions and OTA failures.

Q4. What happens if the network changes during OTA?

If the active network interface changes during OTA:

• TLS sessions are terminated
• Socket connections are dropped
• OTA downloads may fail or restart

For this reason, network switching should be prevented during an OTA transaction.

Q5. Does the Mender MCU Client manage network selection or failover?

No.
Network selection, routing, and failover must be implemented at the system level using Zephyr networking configuration.

7. Summary

• The Mender MCU Client is network-agnostic by design
• Wi-Fi and W5500 Ethernet share the same OTA architecture
• Ethernet improves stability and reduces MCU load in deployment scenarios
• Multiple interfaces can coexist, but OTA should use a single, fixed path

1. 개요

Mender는 대규모 임베디드 디바이스를 대상으로 한 OTA 업데이트 플랫폼으로,
기존에는 Embedded Linux 환경에서 주로 사용되어 왔습니다.

Mender MCU Client는 이러한 OTA 개념을 Zephyr와 같은 RTOS 기반 MCU 환경으로 확장한 구성입니다.
이 환경에서는 전체 파일 시스템이 아닌, MCU 플래시에 저장되는 펌웨어 이미지가 OTA 대상이 됩니다.

ESP32-S3 DevKitC를 기준으로 한 공식 시작 가이드는
Zephyr 애플리케이션에 Mender MCU Client를 통합하고,
Wi-Fi를 통해 OTA 업데이트를 수행하는 전체 흐름을 단계별로 설명합니다.

동시에, Mender는 W5500 Ethernet 컨트롤러를 사용하는 별도의 가이드를 제공하여,
동일한 Zephyr 환경에서 유선 Ethernet 기반 OTA를 구성할 수 있음을 명확히 보여줍니다.

2. Zephyr 환경에서의 Mender MCU Client 구조

Mender MCU Client는 Zephyr의 네트워크 스택 위에서 동작하며,
네트워크 드라이버와 명확히 분리된 구조를 갖습니다.

 

이 구조의 핵심은 다음과 같습니다.

• Mender MCU Client는 네트워크 종류를 인식하지 않습니다.
• 네트워크 선택은 Zephyr의 라우팅과 인터페이스 설정에 의해 결정됩니다.
• OTA 로직은 Wi-Fi와 Ethernet 모두에서 동일하게 유지됩니다.

3. Wi-Fi 기반 OTA의 기술적 특성

ESP32-S3 기본 예제에서 Wi-Fi는 다음과 같은 방식으로 사용됩니다.

• ESP32 내부 Wi-Fi 모듈 사용
• Zephyr net_if를 통해 네트워크 인터페이스 등록
• MCU에서 TCP/IP 및 TLS 처리
• HTTPS 기반 OTA 이미지 다운로드
• 비활성 플래시 슬롯에 펌웨어 기록
• 재부팅 후 업데이트 검증 및 롤백 처리

이 방식은 개발 및 PoC 단계에서는 효율적이지만,
OTA 중 네트워크 품질이 환경에 크게 의존한다는 특성이 있습니다.

4. W5500 Ethernet 통합 시 기술적 변화

W5500 Ethernet을 사용하는 경우 변경되는 부분은 네트워크 드라이버 계층에 한정됩니다.

변경되는 요소

• 네트워크 드라이버: Wi-Fi → W5500 Ethernet
• Zephyr Device Tree:
  • SPI 버스 설정
  • Chip Select
  • 인터럽트 핀
• Ethernet 인터페이스 등록

변경되지 않는 요소

• Mender MCU Client 코드
• OTA 상태 머신
• HTTPS 통신 로직
• 플래시 파티션 구조
• 롤백 처리 방식

W5500은 TCP/IP 스택을 내부에 포함한 하드웨어로,
OTA 중 MCU의 네트워크 처리 부담을 줄이는 데 효과적입니다.

5. Wi-Fi와 W5500 OTA 비교

6. 기술 Q&A: Wi-Fi와 W5500을 동시에 사용할 수 있습니까?

Q1. Wi-Fi와 W5500 Ethernet을 동시에 활성화할 수 있습니까?

가능합니다.
Zephyr는 여러 net_if를 동시에 지원하므로,
Wi-Fi와 Ethernet 인터페이스를 함께 활성화할 수 있습니다.

Q2. OTA 중 두 네트워크를 동시에 사용합니까?

아닙니다.
OTA는 단일 네트워크 경로를 사용해야 하며,
어떤 인터페이스가 사용될지는 Zephyr의 라우팅 설정에 따라 결정됩니다.

Q3. 권장되는 설계 방식은 무엇입니까?

• Ethernet 우선
• Wi-Fi는 fallback 용도
• OTA 중 네트워크 전환 금지

이 구조가 OTA 안정성 측면에서 가장 현실적입니다.

Q4. OTA 중 네트워크 전환 시 발생하는 문제는 무엇입니까?

• TLS 세션 종료
• 소켓 오류
• OTA 실패 또는 재시도 발생

Q5. 네트워크 전환을 Mender MCU Client가 관리합니까?

아닙니다.
네트워크 선택과 전환은 Zephyr 설정과 시스템 설계 영역입니다.

7. 정리

• Mender MCU Client는 네트워크 매체와 분리된 구조를 갖습니다.
• Wi-Fi와 W5500 Ethernet은 동일한 OTA 설계 안에서 선택 가능합니다.
• 운영 환경에서는 Ethernet이 안정성과 부하 측면에서 유리합니다.
• 동시 활성화는 가능하지만 OTA 중에는 단일 경로 사용이 필수입니다.