[UCC Curation | JP] When WiFiClient-W6300.ino won’t work on W6300-EVB-PICO2: the minimum patch that makes it reproducible

This is a curated, third-party-friendly summary of a Japanese Zenn post by kazueda. The original author tried the official Arduino example for W6300-EVB-PICO2 (RP2350), but it failed to get online in their environment—so they modified the sketch and got real Ethernet connectivity working end-to-end (DHCP → TCP connect → payload read).

1) The problem this post solves: “the official example doesn’t work for me”

Following the official WIZnet Maker guide, you open lwIP_w6300 → WiFiClient-W6300.ino, build, and upload. In some setups, users get stuck because the sketch either:

never comes up on Ethernet (e.g., stuck waiting on DHCP / link), or

fails to connect out to the internet.

The Japanese post is valuable because it doesn’t stop at “it didn’t work”—it isolates why and shows the smallest set of changes to make the demo reliable.

2) One crucial background detail: W6300-EVB-PICO2 is not a “standard SPI Ethernet module”

The official guide explains that on W6300 boards the chip runs over QSPI with fixed pin definitions in the library (e.g., CS=16, SCK=17, IO0..IO3=18..21). That means “typical SPI module habits” (setting generic SPI pins, calling SPI.begin() like a normal SPI Ethernet board) can be misleading here.

This single fact explains why a sketch that looks “normal” can still fail on this board.

3) Why it failed (as the author frames it): two root causes

The Zenn post effectively narrows failures to two points:

A) Wrong chip-select argument → the chip isn’t actually selected

If the CS value passed into the driver doesn’t match the board’s actual CS pin, the W6300 is never properly addressed.

B) Treating QSPI hardware like standard SPI → unnecessary / confusing initialization

Because the library already defines QSPI pins for W6300, leaving in “standard SPI setup” code can create confusion or unintended behavior. The author removes those SPI initialization fragments to match the QSPI-fixed reality.

4) The fix: the minimum patch that makes the example work

The strength of this post is how little it changes—just enough to make the demo reproducible.

4.1 Set CS explicitly to GPIO16

This is the “make-or-break” line.

Before

Wiznet6300lwIP eth(1 /* chip select */);

After

Wiznet6300lwIP eth(16);

GPIO16 matches the board/library expectation for the QSPI CS line.

4.2 Remove standard SPI pin setup and SPI.begin()

Since W6300 uses a QSPI path with fixed pins, the author removes code that tries to initialize the W6300 like a generic SPI Ethernet module.

4.3 Add a DHCP/link timeout (avoid infinite “hang”)

Instead of waiting forever in loops like while(!eth.connected()), the author adds a ~10s timeout. This keeps the sketch responsive even if the cable/router/DHCP isn’t ready.

4.4 Handle “server closes early” correctly

The demo connects to a QOTD server. Those servers may respond and close quickly, so only waiting on available() can cause pointless blocking. The author strengthens client.connected() checks so the loop exits cleanly when the server closes.

4.5 Clean up retry policy

They tune the reconnect behavior: slow down once stable (e.g., 5-minute interval), but retry sooner after failures. That makes the demo friendlier in lab/demo setups while avoiding unnecessary load.

(The author also notes they used Copilot for parts of the changes—an honest “how it actually happened” detail.)

5) What “success” looks like (how the post validates it)

The patched sketch reaches a real end-to-end outcome:

Ethernet init → DHCP IP acquired

TCP connect to djxmmx.net:17 (QOTD)

Receive and print the quote

Detect “server closed connection” and continue without hanging

This is a strong validation pattern because it proves more than “link up”—it proves real outbound TCP + payload read.

6) Practical checklist for other users

If you’re trying to reproduce the result, these are the high-impact checks:

You’re using the intended example: lwIP_w6300 → WiFiClient-W6300

CS is set to 16 (eth(16))

You removed generic SPI initialization (QSPI fixed pins are already defined for W6300)

DHCP/link wait loops have a timeout

Client loops handle “server closed” cases correctly

7) Original language & author context (why this JP post is worth curating)

The source is a Japanese Zenn article, posted as part of Raspberry Pi Advent Calendar 2025.

The author describes themselves as someone who likes 8-bit CPUs and MCUs.

The key advantage of this kind of JP UCC is that it’s a real “I tried, it failed, here’s the minimal patch” record—exactly the thing that helps other users avoid the same trap.

References

Original (JP): Zenn article by kazueda

WIZnet Maker Guide: Arduino example + QSPI pin notes for W6300

WIZnet Docs: W6300-EVB-PICO2 overview