How to Build High-Performance Remote Firmware Updates with WIZnet W5500 on STM32?

Summary

This commercial firmware architecture uses WIZnet W5500 with an STM32 microcontroller to perform HTTP-based remote firmware updates through In-Application Programming. The project supports HTTP GET and POST workflows, checksum-based image validation, and a dual-bank rollback concept intended to preserve the previous firmware when an update fails. W5500 supplies the Ethernet MAC/PHY, hardwired TCP/IP processing, socket engine, and network buffers, while the STM32 manages HTTP data, Flash programming, image verification, boot selection, and rollback. The exact STM32 model and source implementation are not visible on the accessible GitCode page, so target-specific Flash timing and update throughput must be measured on the selected MCU.

What the Project Does

The project provides an STM32 remote-update design built around W5500 and IAP. Its description identifies HTTP GET and POST as the firmware-transfer methods and presents a dual-bank strategy for returning to a stable image after an interrupted or invalid update. It also mentions checksum validation as a basic integrity measure.

A commercial implementation follows this data path:

Firmware server or management tool → Ethernet network → W5500 TCP socket → SPI → STM32 update manager → inactive firmware bank → image verification → boot-selection metadata → controlled restart

The HTTP direction depends on the product design:

In a pull model, the STM32 opens a TCP connection and issues an HTTP GET request for a firmware image.

In a push model, a maintenance system uploads an image using HTTP POST to a service running on the device.

The project states that both methods are supported, but its accessible page does not expose enough source code to determine the exact server/client roles, HTTP parser, Flash layout, resume mechanism, or activation sequence.

For a commercial device, the updater should be divided into independently testable stages:

Discover or configure the update server.

Establish the W5500 TCP connection.

Validate the HTTP response or upload metadata.

Stream the image into the inactive Flash region.

Verify length, integrity, authenticity, hardware compatibility, and version policy.

Mark the new image as pending.

Reboot and perform a controlled trial boot.

Commit the new image or return to the previous version.

This separation prevents a network timeout, malformed HTTP message, Flash error, or failed application startup from leaving the device without a recoverable image.

Where WIZnet Fits

The exact WIZnet product is W5500. It is connected to the STM32 through SPI and sits between the firmware-update application and the physical Ethernet network.

W5500 integrates a 10/100 Ethernet MAC and PHY, a hardwired IPv4 TCP/IP stack, eight hardware sockets, and 32 KB of internal Tx/Rx memory. Its host interface supports SPI operation up to 80 MHz. WIZnet also provides an MCU-independent ioLibrary_Driver with Berkeley-style socket APIs for W5500 and related devices.

In this update architecture, W5500 handles:

Ethernet link establishment

ARP and IPv4 processing

TCP connection state

Packet retransmission

Socket status

Network-side Tx/Rx buffering

The STM32 handles:

HTTP request and response parsing

Firmware metadata

Flash erase and programming

Integrity and signature verification

Image-version policy

Boot-bank selection

Watchdog and rollback control

W5500 does not authenticate the firmware and does not provide TLS termination by itself. A commercial updater must implement image authenticity in the STM32 boot chain or through a suitable security component. A CRC or checksum can detect accidental corruption, but it does not prove that an image came from an authorized publisher.

Implementation Notes

The visible GitCode repository confirms the STM32, W5500, HTTP, IAP, and rollback concept, but it does not expose inspectable project source files. The repository-specific Flash addresses, socket allocation, buffer sizes, HTTP state machine, boot metadata, and error handling therefore cannot be quoted reliably.

Update pipeline

A practical implementation should use a streaming pipeline rather than storing the complete firmware image in STM32 RAM:

W5500 socket Rx buffer → STM32 RAM buffer A → Flash programming
W5500 socket Rx buffer → STM32 RAM buffer B → Flash programming

With two RAM buffers, one block can be programmed while the other is being received or prepared. Whether network reception can continue during Flash programming depends on the STM32 family, Flash organization, interrupt placement, and whether code is executing from the bank being programmed.

For an STM32 with true dual-bank Flash, firmware can execute from one bank while the other bank is updated, subject to that MCU’s reference-manual restrictions. ST’s dual-bank update package demonstrates automatic and manual bank selection, vector-table relocation, and on-the-fly firmware-update concepts for supported STM32 devices. The project’s generic “STM32 series” description is not enough to guarantee that every target provides this behavior.

Performance model

The approximate update time can be treated as:

erase time + image size / sustained pipeline rate + verification time + reboot and trial-boot time

The sustained pipeline rate is limited by the slowest active stage:

HTTP/TCP receive rate

W5500 SPI transfer rate

HTTP parsing and copying

STM32 Flash programming rate

Integrity or signature calculation

Server response behavior

An 80 MHz-capable W5500 SPI interface does not imply an 80 Mbps firmware-update rate. SPI transactions also carry addresses and control bytes, while HTTP, TCP, IP, and Ethernet add protocol overhead. Flash erase and programming may become the dominant bottleneck.

WIZnet’s own STM32F103 performance examples show that measured TCP throughput changes with SPI clock, MCU buffer size, and W5500 socket-buffer allocation. Those figures are not benchmarks for this repository, but they demonstrate why update performance must be measured using the actual MCU, firmware image size, SPI configuration, Flash layout, and network peer.

Buffer allocation

The update TCP socket should receive enough of W5500’s internal memory to tolerate short delays caused by Flash programming or signature calculation. Other sockets used for diagnostics, service access, or operational traffic should receive explicitly reserved memory.

On the STM32 side, buffer size should be selected according to:

Available SRAM

Flash programming granularity

HTTP header handling

Maximum processing pause

Watchdog servicing requirements

Required operational tasks during the update

Very small buffers increase SPI and Flash-call overhead. Very large buffers consume SRAM and may increase the amount of data lost when a transfer is interrupted.

Image activation and rollback

A robust A/B update should keep the currently working image untouched until the replacement image has passed all required checks. Boot metadata should distinguish at least:

Current confirmed image

Download target

Pending image

Trial-boot image

Confirmed replacement

Rollback reason

Boot success should not be declared immediately after reset. The new application should first complete critical initialization and report a health confirmation to the bootloader or persistent update manager. If it resets repeatedly, exceeds a startup deadline, or fails an application health check, the boot process should return to the previous confirmed image.

Commercial security

The source mentions checksum verification and recommends stronger protection for production deployments. A commercial design should add:

Cryptographic firmware signatures

A trusted public key stored outside writable application memory

Product and hardware-revision checks

Monotonic version or anti-rollback policy

Protected update metadata

Authentication for update commands

Confidential transport when firmware disclosure matters

The firmware image should be authenticated before activation. A network connection completing successfully is not evidence that the image is authorized.

Practical Tips / Pitfalls

Measure network reception, Flash erase, Flash programming, verification, and reboot time separately before optimizing the complete updater.

Use two RAM buffers so SPI reception and Flash handling can be pipelined where the selected STM32 permits it.

Keep the existing confirmed image bootable until the replacement has passed integrity, signature, compatibility, and trial-boot checks.

Feed the watchdog only from a state machine that is making valid progress; a stalled HTTP connection must not keep the updater alive indefinitely.

Record image version, expected length, received length, verification result, boot attempts, rollback reason, socket error, and update duration.

Test power loss during erase, programming, metadata update, bank switching, first boot, and confirmation.

Benchmark with realistic image sizes, server latency, packet loss, SPI speed, Flash configuration, and simultaneous product workloads.

FAQ

Q: Why use WIZnet W5500 for commercial STM32 firmware updates?
A: W5500 moves Ethernet MAC/PHY operation, IPv4, TCP state, retransmission, socket control, and packet buffering out of the STM32 software stack. This gives the update firmware a defined socket interface and leaves more MCU resources for HTTP processing, Flash programming, image verification, boot control, and application health checks.

Q: How does W5500 connect to the STM32 platform?
A: W5500 connects through SPI using SCLK, MOSI, MISO, and chip select, together with reset and optionally interrupt. Reset should be controlled by an STM32 GPIO so the network subsystem can be recovered without resetting the entire product. The update firmware should verify SPI communication, chip identity, PHY link, IP configuration, and socket state before beginning a Flash operation.

Q: What role does W5500 play during the firmware update?
A: W5500 transports the HTTP request, response, or upload through a TCP socket and buffers the incoming network data. STM32 retrieves those bytes through SPI, parses the HTTP message, programs the inactive firmware region, validates the completed image, and controls activation or rollback.

Q: Can beginners follow this project?
A: The networking portion is approachable, but a production-safe updater requires experience with linker scripts, vector-table relocation, Flash erase/program rules, bootloaders, watchdogs, persistent metadata, and failure testing. A suitable learning sequence is TCP download to RAM, streamed download without Flash writes, single-slot IAP on a development board, A/B image selection, power-loss recovery, and finally authenticated commercial updates.

Q: How does W5500 compare with an STM32 Ethernet MAC running LwIP?
A: W5500 provides an external PHY, hardwired TCP/IP engine, sockets, and packet memory behind SPI. An STM32 Ethernet MAC with LwIP uses an external PHY and executes the TCP/IP stack in MCU firmware, giving the application deeper control over buffers, protocols, and integration. LwIP can suit high-integration STM32 devices with sufficient RAM and processing capacity, while W5500 reduces software-stack responsibility and provides a more explicit offload boundary. Actual update performance depends on the selected STM32, SPI or DMA implementation, Flash speed, buffer design, and network conditions rather than the architecture name alone.

Source

Original project: GitCode, “STM32_IAP远程升级程序-基于STM32W5500与IAP技术.” The visible page identifies STM32, W5500, HTTP GET/POST firmware transfer, IAP, remote maintenance, three repository commits, and an MIT license marker. It does not expose inspectable implementation files through the accessible view.

Related project description: CSDN, “STM32_IAP远程升级程序 - 基于STM32、W5500与IAP技术.” The article describes HTTP GET/POST updates, dual-bank rollback, checksum verification, setup steps, and production-security cautions. It is published under CC 4.0 BY-SA and states that part of its content was AI-assisted.

WIZnet references: Official W5500 documentation, SPI performance examples, and ioLibrary_Driver. These sources document W5500’s hardwired TCP/IP architecture, sockets, internal memory, SPI interface, socket APIs, and the dependence of measured throughput on host and buffer configuration.

STM32 dual-bank reference: STMicroelectronics X-CUBE-DBFU, which demonstrates on-the-fly firmware updates, bank selection, and vector-table relocation on supported dual-bank STM32 devices.

Tags

#W5500 #WIZnet #STM32 #IAP #FirmwareUpdate #HTTP #DualBank #Rollback #CommercialIoT #Ethernet #Bootloader #Performance

STM32에서 WIZnet W5500으로 고성능 원격 펌웨어 업데이트를 구현하는 방법은?

요약

이 상용 펌웨어 아키텍처는 STM32 마이크로컨트롤러와 WIZnet W5500을 사용해 IAP(In-Application Programming) 기반 HTTP 원격 펌웨어 업데이트를 수행합니다. 프로젝트는 HTTP GET 및 POST 방식, 체크섬 기반 이미지 검증, 업데이트 실패 시 이전 펌웨어로 복귀하기 위한 듀얼 뱅크 롤백 개념을 지원합니다. W5500은 Ethernet MAC/PHY, 하드웨어 TCP/IP 처리, 소켓 엔진, 네트워크 버퍼를 제공하고, STM32는 HTTP 데이터 처리, Flash 프로그래밍, 이미지 검증, 부팅 이미지 선택, 롤백을 담당합니다. 접근 가능한 GitCode 페이지에서는 정확한 STM32 모델과 실제 소스 구현을 확인할 수 없으므로, 대상 MCU의 Flash 처리 시간과 업데이트 처리량은 실제 하드웨어에서 측정해야 합니다.

프로젝트가 하는 일

이 프로젝트는 W5500과 IAP를 기반으로 한 STM32 원격 업데이트 구조를 제공합니다. 프로젝트 설명에서는 HTTP GET과 POST를 펌웨어 전송 방식으로 사용하고, 업데이트 중단 또는 잘못된 이미지가 발생했을 때 기존의 정상 이미지로 복귀하기 위한 듀얼 뱅크 방식을 제시합니다. 기본적인 무결성 확인 수단으로 체크섬 검증도 언급합니다.

상용 구현의 데이터 흐름은 다음과 같습니다.

펌웨어 서버 또는 관리 도구 → Ethernet 네트워크 → W5500 TCP 소켓 → SPI → STM32 업데이트 관리자 → 비활성 펌웨어 뱅크 → 이미지 검증 → 부팅 선택 메타데이터 → 제어된 재시작

HTTP 전송 방향은 제품 설계에 따라 달라질 수 있습니다.

Pull 방식: STM32가 TCP 연결을 열고 펌웨어 이미지에 대한 HTTP GET 요청을 전송합니다.

Push 방식: 유지보수 시스템이 장치에서 실행되는 HTTP 서비스에 POST 방식으로 펌웨어 이미지를 업로드합니다.

프로젝트는 두 방식을 모두 지원한다고 설명하지만, 접근 가능한 페이지에서는 정확한 클라이언트 및 서버 역할, HTTP parser, Flash layout, 중단 후 재개 기능, 이미지 활성화 순서를 확인할 수 없습니다.

상용 장치의 업데이트 기능은 다음 단계로 분리해 독립적으로 테스트하는 것이 적절합니다.

업데이트 서버를 검색하거나 주소를 설정합니다.

W5500 TCP 연결을 생성합니다.

HTTP 응답 또는 업로드 메타데이터를 검증합니다.

펌웨어 이미지를 비활성 Flash 영역에 스트리밍 방식으로 기록합니다.

길이, 무결성, 진위성, 하드웨어 호환성, 버전 정책을 확인합니다.

새 이미지를 대기 상태로 표시합니다.

재부팅 후 제한된 시험 부팅을 수행합니다.

새 이미지를 확정하거나 이전 버전으로 복귀합니다.

이와 같은 단계 분리는 네트워크 타임아웃, 잘못된 HTTP 메시지, Flash 오류, 새 애플리케이션의 부팅 실패로 인해 장치가 복구 불가능한 상태가 되는 것을 방지합니다.

WIZnet이 들어가는 위치

이 프로젝트에서 사용하는 정확한 WIZnet 제품은 W5500입니다. W5500은 SPI를 통해 STM32와 연결되며, 펌웨어 업데이트 애플리케이션과 물리적 Ethernet 네트워크 사이에 위치합니다.

W5500은 다음 기능을 통합합니다.

10/100 Ethernet MAC 및 PHY

하드웨어 IPv4 TCP/IP 스택

8개의 하드웨어 소켓

32KB 내부 송수신 메모리

최대 80MHz SPI 호스트 인터페이스

WIZnet은 W5500 및 관련 제품에서 사용할 수 있는 MCU 독립형 ioLibrary_Driver도 제공하며, Berkeley socket 방식의 API를 포함합니다.

이 업데이트 아키텍처에서 W5500은 다음을 담당합니다.

Ethernet 링크 연결

ARP 및 IPv4 처리

TCP 연결 상태

패킷 재전송

소켓 상태 관리

네트워크 측 송수신 버퍼링

STM32는 다음을 담당합니다.

HTTP request 및 response parsing

펌웨어 메타데이터 관리

Flash 삭제 및 프로그래밍

무결성 및 서명 검증

이미지 버전 정책

부팅 뱅크 선택

Watchdog 및 rollback 제어

W5500은 펌웨어의 진위성을 검증하지 않으며 자체적으로 TLS를 종료하지도 않습니다. 상용 업데이트 기능에서는 STM32 부팅 체인 또는 별도의 보안 부품을 사용해 이미지 진위성을 검증해야 합니다. CRC 또는 체크섬은 우발적인 데이터 손상을 감지할 수 있지만, 해당 이미지가 승인된 배포자로부터 제공되었다는 사실을 증명하지는 못합니다.

구현 참고 사항

Visible GitCode repository에서는 STM32, W5500, HTTP, IAP, rollback 개념을 확인할 수 있지만, 실제 프로젝트 소스 파일은 노출하지 않습니다. 따라서 프로젝트 고유의 Flash 주소, 소켓 할당, 버퍼 크기, HTTP state machine, boot metadata, error handling은 신뢰성 있게 인용할 수 없습니다.

업데이트 파이프라인

실용적인 구현에서는 전체 펌웨어 이미지를 STM32 RAM에 저장하지 않고 스트리밍 파이프라인을 사용해야 합니다.

W5500 소켓 Rx 버퍼 → STM32 RAM 버퍼 A → Flash 프로그래밍
W5500 소켓 Rx 버퍼 → STM32 RAM 버퍼 B → Flash 프로그래밍

두 개의 RAM 버퍼를 사용하면 한 블록을 Flash에 기록하는 동안 다른 블록을 수신하거나 처리할 수 있습니다. Flash 프로그래밍 중에도 네트워크 수신을 계속할 수 있는지는 STM32 제품군, Flash 구조, interrupt code 위치, 현재 실행 중인 뱅크와 프로그래밍 대상 뱅크의 관계에 따라 달라집니다.

실제 듀얼 뱅크 Flash를 제공하는 STM32에서는 해당 MCU reference manual의 제한 조건에 따라 한 뱅크에서 코드를 실행하면서 다른 뱅크를 업데이트할 수 있습니다. ST의 듀얼 뱅크 업데이트 패키지는 지원되는 STM32 장치에서 자동 및 수동 bank selection, vector-table relocation, on-the-fly firmware update 개념을 보여줍니다. 그러나 프로젝트 설명이 단순히 “STM32 series”라고만 되어 있으므로 모든 STM32가 동일한 기능을 제공한다고 가정하면 안 됩니다.

성능 모델

대략적인 업데이트 시간은 다음과 같이 계산할 수 있습니다.

Flash 삭제 시간 + 이미지 크기 / 지속 파이프라인 속도 + 검증 시간 + 재부팅 및 시험 부팅 시간

지속적인 파이프라인 속도는 다음 단계 중 가장 느린 부분에 의해 제한됩니다.

HTTP/TCP 수신 속도

W5500 SPI 전송 속도

HTTP parsing 및 memory copy

STM32 Flash 프로그래밍 속도

무결성 또는 서명 계산

펌웨어 서버의 응답 특성

W5500이 최대 80MHz SPI를 지원한다고 해서 펌웨어 업데이트 속도가 80Mbps라는 의미는 아닙니다. SPI transaction에는 address와 control byte가 포함되며, HTTP, TCP, IP, Ethernet에도 protocol overhead가 존재합니다. Flash 삭제 및 프로그래밍이 전체 성능의 주된 병목이 될 수도 있습니다.

WIZnet의 STM32F103 performance example에서도 TCP throughput은 SPI clock, MCU buffer size, W5500 socket-buffer allocation에 따라 달라집니다. 해당 수치는 이 repository의 benchmark는 아니지만, 실제 업데이트 성능을 평가하려면 MCU, image size, SPI configuration, Flash layout, network peer를 동일하게 정의해야 한다는 점을 보여줍니다.

버퍼 할당

업데이트용 TCP socket에는 Flash 프로그래밍 또는 signature calculation 중 발생하는 짧은 지연을 흡수할 수 있도록 충분한 W5500 internal memory를 할당해야 합니다. Diagnostics, service access, operational traffic에 사용되는 다른 socket에도 명시적으로 memory를 예약해야 합니다.

STM32 측 버퍼 크기는 다음 조건에 따라 결정해야 합니다.

사용 가능한 SRAM

Flash programming granularity

HTTP header 처리 방식

허용 가능한 최대 처리 중단 시간

Watchdog servicing 요구 사항

업데이트 중 유지해야 하는 제품 기능

버퍼가 지나치게 작으면 SPI transaction 및 Flash programming call overhead가 증가합니다. 반대로 버퍼가 너무 크면 SRAM 사용량이 증가하고, 전송 중단 시 손실되는 데이터 단위도 커질 수 있습니다.

이미지 활성화 및 롤백

안정적인 A/B 업데이트에서는 새 이미지가 모든 검증을 통과할 때까지 현재 정상 이미지를 변경하지 않아야 합니다.

Boot metadata는 최소한 다음 상태를 구분해야 합니다.

현재 확정된 이미지

다운로드 대상 영역

대기 중인 이미지

시험 부팅 이미지

확정된 새 이미지

롤백 원인

Reset 직후 즉시 부팅 성공으로 처리하면 안 됩니다. 새 애플리케이션은 필수 초기화를 완료하고 bootloader 또는 persistent update manager에 정상 상태를 알려야 합니다. 반복적으로 reset되거나, 정해진 시간 안에 시작되지 않거나, application health check를 통과하지 못하면 이전에 확정된 이미지로 복귀해야 합니다.

상용 보안

원본 자료는 checksum verification을 언급하며 실제 제품에서는 더 강한 보호가 필요하다고 설명합니다. 상용 설계에서는 다음 기능을 추가해야 합니다.

암호학적 펌웨어 서명

쓰기 가능한 application memory 외부에 저장된 신뢰된 public key

제품 및 hardware revision 확인

Monotonic version 또는 anti-rollback 정책

보호된 update metadata

Update command 인증

펌웨어 노출을 방지해야 하는 경우 암호화된 전송

펌웨어 이미지는 활성화 전에 반드시 인증되어야 합니다. 네트워크 전송이 정상적으로 완료되었다는 사실만으로 해당 이미지가 승인된 이미지라는 것을 보장할 수 없습니다.

실무 팁 / 주의점

전체 updater를 최적화하기 전에 네트워크 수신, Flash 삭제, Flash 프로그래밍, 검증, 재부팅 시간을 각각 측정해야 합니다.

선택한 STM32에서 허용된다면 두 개의 RAM 버퍼를 사용해 SPI 수신과 Flash 처리를 파이프라인화해야 합니다.

새 이미지가 무결성, 서명, 호환성, 시험 부팅 검증을 통과할 때까지 기존 정상 이미지를 부팅 가능한 상태로 유지해야 합니다.

Watchdog은 업데이트 state machine이 실제로 유효한 진행을 하고 있을 때만 갱신해야 합니다. 정지된 HTTP 연결이 무한정 updater를 유지하게 하면 안 됩니다.

Image version, expected length, received length, verification result, boot attempts, rollback reason, socket error, update duration을 기록해야 합니다.

Flash 삭제, programming, metadata update, bank switching, first boot, confirmation 단계에서 각각 전원 차단 테스트를 수행해야 합니다.

실제 firmware image size, server latency, packet loss, SPI speed, Flash configuration, simultaneous product workload 조건으로 benchmark해야 합니다.

FAQ

Q: 상용 STM32 펌웨어 업데이트에 왜 WIZnet W5500을 사용하나요?
A: W5500은 Ethernet MAC/PHY, IPv4, TCP state, retransmission, socket control, packet buffering을 STM32 software stack 밖에서 처리합니다. 따라서 update firmware는 명확한 socket interface를 사용하고, MCU resource를 HTTP 처리, Flash programming, image verification, boot control, application health check에 더 집중할 수 있습니다.

Q: W5500은 STM32 platform에 어떻게 연결되나요?
A: W5500은 SCLK, MOSI, MISO, chip select를 사용하는 SPI로 연결되며, reset과 선택적인 interrupt signal도 사용합니다. Reset은 STM32 GPIO로 제어해 전체 product를 reset하지 않고 network subsystem만 복구할 수 있게 해야 합니다. Flash 작업을 시작하기 전에 SPI communication, chip identity, PHY link, IP configuration, socket state를 확인해야 합니다.

Q: 펌웨어 업데이트 중 W5500은 어떤 역할을 하나요?
A: W5500은 HTTP request, response 또는 upload data를 TCP socket으로 전송하고 incoming network data를 내부 buffer에 저장합니다. STM32는 SPI를 통해 해당 byte를 읽고, HTTP message를 parsing하며, 비활성 firmware 영역을 programming하고, image validation과 activation 또는 rollback을 제어합니다.

Q: 초보자도 이 프로젝트를 따라갈 수 있나요?
A: Networking 부분은 비교적 접근하기 쉽지만, production-safe updater를 구현하려면 linker script, vector-table relocation, Flash erase/program rule, bootloader, watchdog, persistent metadata, failure testing 경험이 필요합니다. 권장 학습 순서는 TCP download to RAM, Flash write 없는 streaming download, development board에서의 single-slot IAP, A/B image selection, power-loss recovery, authenticated update입니다.

Q: W5500은 LwIP를 사용하는 STM32 Ethernet MAC과 어떻게 다른가요?
A: W5500은 external PHY, hardwired TCP/IP engine, socket, packet memory를 SPI 뒤에 제공합니다. STM32 Ethernet MAC과 LwIP 조합은 external PHY를 사용하고 TCP/IP stack을 MCU firmware에서 실행하므로 buffer, protocol, integration에 대해 더 많은 제어권을 제공합니다. 충분한 RAM과 처리 성능을 가진 STM32에서는 LwIP가 적합할 수 있으며, W5500은 software stack 책임을 줄이고 명확한 offload boundary를 제공합니다. 실제 업데이트 성능은 architecture 명칭보다 선택한 STM32, SPI 또는 DMA 구현, Flash 속도, buffer 설계, network condition에 더 크게 좌우됩니다.

출처

원본 프로젝트: GitCode, “STM32_IAP远程升级程序-基于STM32W5500与IAP技术.” Visible page에서는 STM32, W5500, HTTP GET/POST firmware transfer, IAP, remote maintenance, repository commit, MIT license marker를 확인할 수 있지만, accessible view에서는 inspect 가능한 implementation file을 제공하지 않습니다.
https://gitcode.com/open-source-toolkit/fa0e1

관련 프로젝트 설명: CSDN, “STM32_IAP远程升级程序 - 基于STM32、W5500与IAP技术.” 해당 글은 HTTP GET/POST update, dual-bank rollback, checksum verification, setup step, production-security caution을 설명합니다. CC 4.0 BY-SA로 게시되었으며 일부 내용이 AI-assisted라고 명시되어 있습니다.
https://blog.csdn.net/gitblog_09787/article/details/141945131

WIZnet 참고 자료: W5500 공식 documentation, SPI performance example, ioLibrary_Driver. W5500의 hardwired TCP/IP architecture, socket, internal memory, SPI interface, socket API, host 및 buffer configuration에 따른 throughput 변화를 설명합니다.
https://docs.wiznet.io/Product/Chip/Ethernet/W5500
https://docs.wiznet.io/Product/Chip/Ethernet/W5500/Application/spi-performance
https://github.com/Wiznet/ioLibrary_Driver

STM32 듀얼 뱅크 참고 자료: STMicroelectronics X-CUBE-DBFU. 지원되는 dual-bank STM32에서 on-the-fly firmware update, bank selection, vector-table relocation 예제를 제공합니다.
https://www.st.com/en/embedded-software/x-cube-dbfu.html

태그

#W5500 #WIZnet #STM32 #IAP #FirmwareUpdate #HTTP #DualBank #Rollback #CommercialIoT #Ethernet #Bootloader #Performance