Why Does W5500 TCP “Send OK but No Data”?

A Driver-Level Debugging Guide to TCP Socket Lifecycle and SPI Discipline

(W5500에서 TCP 전송은 성공인데 데이터가 없는 이유는 무엇일까? – 드라이버 수준 디버깅 가이드)

Summary (40–60 words)

This article analyzes a common W5500 failure case where TCP connections succeed and SEND commands return OK, yet no data reaches the peer. By walking through the real TCP socket lifecycle, SPI multi-byte access rules, and TX buffer handling, it explains why driver-level mistakes—especially CS timing—cause silent data loss, and how to fix them deterministically.

1. The Symptom: TCP Works… Except the Data

The video BV1Ce41127gD demonstrates a situation many engineers encounter:

TCP socket opens successfully

Connection reaches ESTABLISHED

SEND command is issued without error

Remote side receives nothing

No reset.
No error flag.
No obvious failure.

This is one of the most dangerous classes of bugs in embedded Ethernet:

TCP appears healthy, but application data silently disappears.

2. Why This Is Not a TCP Problem

On W5500, TCP/IP is implemented entirely in hardware.
This means:

Retransmission logic is correct

Sequence numbers are handled

ACKs are managed internally

If the socket reaches ESTABLISHED, the TCP protocol itself is working.

Therefore, when data is missing, the root cause is almost always below TCP, in:

SPI transactions

Register sequencing

TX buffer pointer handling

3. Real TCP Socket Lifecycle on W5500 (Hardware Perspective)

Understanding this failure requires mapping the real hardware lifecycle, not the abstract TCP model.

Simplified Lifecycle

In the video, the system successfully reaches ESTABLISHED, which proves:

SPI works sometimes

Basic register access is correct

PHY and link are stable

The failure occurs between “write TX buffer” and “SEND”.

4. What SEND Actually Does Inside W5500

This is the critical misunderstanding.

When the MCU issues a SEND command, W5500:

Reads the TX write pointer

Calculates how much data is pending

Copies that data from the TX buffer

Transmits it via the TCP engine

W5500 does not validate your payload.
It sends exactly what the buffer pointers indicate.

If the pointer is wrong, TCP still sends—just with zero or garbage payload.

5. The Root Cause Category: Broken Atomicity

The failure shown in the video matches a classic driver-level issue:

❌ Non-atomic TX buffer operations

Typical causes include:

Splitting multi-byte SPI writes across CS toggles

Writing payload bytes one-by-one with separate CS cycles

Updating TX write pointer incorrectly or too early

Mixing register access and buffer access inconsistently

All of these break internal pointer consistency.

6. Why CS Timing Is the Silent Killer

W5500 SPI uses Variable Length Data Mode (VDM).

This means:

CS LOW duration defines a single logical operation.

Correct Pattern (Conceptual)

Incorrect (But Very Common) Pattern

This breaks:

Address auto-increment

Buffer continuity

TX pointer expectations

The result is exactly what the video shows:

SEND succeeds, but data is empty.

7. Why This Bug Is Hard to See

This failure mode is deceptive because:

Socket state looks correct

No error interrupt is raised

Logic analyzer shows SPI activity

Wireshark shows TCP packets (but no payload)

Engineers often waste time debugging:

Server code

Firewall rules

TCP timing

When the real issue is CS discipline.

8. Practical Debug Checklist (Driver-Level)

If you see “send OK but no data”, check the following in order:

Is payload written in one CS window?

Is TX write pointer updated after payload write?

Are multi-byte registers written atomically?

Is SEND issued only after pointer update?

Is CS controlled only inside the driver?

If any answer is “no”, the bug is almost certainly there.

9. Why Deterministic SPI + Buffer Model Solves This

When the driver enforces:

One operation = one CS window

Multi-byte access only

Clear register → buffer → command sequencing

Then:

TCP becomes reliable

Bugs become reproducible

Firmware becomes portable across MCUs and RTOSes

This is why W5500 is widely used in industrial systems—but only when the driver is written correctly.

10. Key Takeaway

On W5500, TCP data integrity is a driver-level responsibility, not a TCP-level one.

If SPI access is deterministic and buffer pointers are correct:

TCP “just works”

SEND always means “data sent”

Debugging becomes straightforward

FAQ (Failure-Focused)

Q1. Why does SEND return success if data is missing?
Because W5500 only checks socket state, not payload validity.

Q2. Can this happen even if SPI speed is low?
Yes. This is a logic issue, not a timing margin issue.

Q3. Does this affect UDP too?
Yes, but TCP makes it more visible.

Q4. Is this RTOS-specific?
No. It happens in bare-metal and RTOS systems alike.

Q5. How do I prevent this permanently?
Enforce atomic SPI transactions at the driver layer.

Source

Bilibili video: BV1Ce41127gD

WIZnet W5500 Datasheet (SPI & TX/RX buffer architecture)

Tags

W5500, WIZnet, TCP Debugging, SPI CS Timing, TX Buffer, Embedded Ethernet, Driver-Level Design, Industrial IoT

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

W5500에서 TCP 전송은 성공인데 데이터가 없는 이유는 무엇일까?

TCP 소켓 생명주기와 SPI 규율을 통한 드라이버 수준 디버깅

요약

본 문서는 W5500에서 TCP 연결과 SEND 명령은 정상이나 실제 데이터가 전달되지 않는 대표적인 실패 사례를 분석한다. TCP 소켓 생명주기, SPI 다중 바이트 접근, TX 버퍼 포인터 동작을 통해 이러한 문제가 대부분 CS 타이밍과 드라이버 원자성 위반에서 발생함을 설명한다.

1. 증상: TCP는 정상, 데이터는 없음

소켓 연결 성공

ESTABLISHED 상태 유지

SEND 호출 성공

수신 측 데이터 없음

이는 TCP 문제가 아니다.

2. 왜 TCP 자체의 문제가 아닌가

W5500은 TCP/IP를 하드웨어로 처리한다.
연결이 성립되었다면 TCP 스택은 정상이다.

문제는 드라이버 계층에 있다.

3. 실제 W5500 TCP 소켓 생명주기

문제는 TX 버퍼 작성과 SEND 사이에서 발생한다.

4. SEND 명령의 실제 의미

SEND는:

TX 포인터를 기준으로

버퍼에 있는 데이터를 그대로 전송한다

포인터가 잘못되면 빈 데이터도 그대로 전송된다.

5. 핵심 원인: 원자성 붕괴

CS 분리

바이트 단위 접근

포인터 업데이트 오류

이 모두가 동일한 문제를 만든다.

6. CS 타이밍이 중요한 이유

VDM 모드에서:

CS = 트랜잭션 경계

중간에 CS를 올리면 동작은 정의되지 않는다.

7. 왜 디버깅이 어려운가

에러 없음

소켓 상태 정상

패킷은 보이지만 페이로드 없음

그래서 많은 엔지니어가 TCP를 의심한다.

8. 실전 디버깅 체크리스트

페이로드는 한 번의 CS로 작성되는가

TX 포인터는 나중에 갱신되는가

다중 바이트 접근이 유지되는가

9. 결정적인 SPI 모델의 가치

재현 가능성

이식성

산업용 안정성

10. 핵심 메시지

W5500에서 TCP 데이터 무결성은 드라이버의 책임이다.

태그

W5500, WIZnet, TCP 디버깅, SPI CS 타이밍, TX 버퍼, 임베디드 이더넷