v3.3 is v3.2 with the four gaps a full code analysis found in it closed. v3.2 was already the first firmware that recovers by itself from every chip fault we could reproduce. v3.3 also recovers from a PHY held in reset, gets a stuck link back on its own, can spot a deaf receiver on networks without a gateway, measures its own supply, and sends one ARP request per check instead of twenty. It was tested overnight against v2.2, v3.1 and v3.2 on the same real box. Nothing a customer or control system sees has changed.
Adopt v3.3 as the official EPS firmware, in place of v2.2 (field) and v3.2 (previous recommendation).
v3.2 was already the first firmware that recovered by itself from every chip fault we had reproduced. A full code analysis then found four gaps in its self-check, and the overnight tests confirmed them: a PHY held in reset leaves v3.2 dead until a power cycle, and its deaf-receiver check stops testing anything once the gateway has answered once. v3.3 closes these gaps. On the same real box it recovered from all 17 single-register chip faults (51 trials, 3–10 s, outputs never moved), brought a stuck link back with nothing but its new link-down recovery, made no false resets when the gateway vanished, and passed the whole regression suite. It also measures its own supply, which matters because the leading explanation for the field dropouts is a supply sag.
One result is not clean and is reported as such: twice in 40 chip-reset trials the network chip came back deaf after its re-init (it transmitted but answered nothing) for 38 s and about 3.5 minutes, then recovered by itself. This is the rare "deaf after a link negotiation" state the investigation found on another board; v3.3's new check is built for it but needs ~6 minutes on this bench, so faster detection is the next step. This is a bench result, not field proof. The recommended path: make v3.3 official, run the supply-sag test, then pilot it.
v2.2, v3.1 and v3.2 were read in full, together with the Arduino Ethernet library v2.2 runs on, against the W5500 datasheet, the network RFCs and AVR hardware practice (2026-10-12).
BOD=2.7 (v3.3 reads the fuse).Full analysis with code references and datasheet quotes: docs/code-analysis.md in the firmware repository · full report
Everything a customer, installer or control system sees stays the same: outputs, timing, inputs, LED, the TCP protocol, web URLs and stored settings. The changes are in how the unit watches and repairs its own network chip.
The 5 s self-check also compares the PHY reset bit. If the PHY is held in reset, the chip is set up again, as for any other wrong register.
After 30 s without link the PHY is reset, then after 60 s, 120 s … up to ~32 min while it stays down. With the cable really out this does no harm.
Once a minute, one ARP request to the gateway or, where none answers, to the last client on the subnet. For 2 s the chip listens to every frame. A check counts as silent only if nothing at all was heard; three silent checks in a row reset the PHY. This works on closed networks, keeps working after a link-up, ignores a gateway that has simply gone away while other traffic is heard, and sends one ARP request per check instead of 20.
The 5 V rail is measured continuously against the chip's internal reference. NET_STATUS shows VCC, VCC_MIN and the brown-out fuse BOD, and every chip re-init is logged with the lowest supply of the 5 s before it.
An over-long web request now gets 414 instead of 400 (RFC 9112).
| What was tested (unit 3, 2026-10-12) | v3.2 | v3.3 |
|---|---|---|
| Original 14 single-register faults, 3 trials each | all recovered (2026-10-11) | all recovered, 3–10 s |
| PHY held in reset (new fault, G1) | dead 3/3 (power cycle needed) | recovered 3–6 s (3/3) |
| PHY held in reset, only the link-down recovery active (G2) | — | recovered 40 s (3/3) |
| PHY power-down, the field-matching fault | recovered 11–12 s | recovered 4–6 s |
| Gateway disappears, 12 min watched (G3) | no ARP at all after it vanished: the check kept "succeeding" on a cached address | one ARP request per check, no false PHY reset |
| Deaf receiver (emulated, G3) | cannot be detected (see above) | one PHY reset after three silent checks (6 min), none after |
| Link down 180 s, cable side (G2) | — | service back 8.3–8.6 s after the link returned (2/2); 2 PHY resets during each outage, no restart, outputs kept |
| Everyday behaviour (power, load, junk input, HTTP, persistent clients, idle connections, DHCP, 10 Mbps, 50 start-ups, rollover) | passed on v3.1 (same network layer) | all passed; 414 for an over-long request |
| Settings loss (chip reset by command) | v3.1: 30/30 recovered | 38/40 recovered in 2–8 s; twice the chip came back deaf for 38 s / ~3.5 min and cleared by itself (captured once) |
| Network-standard requirements, of 56 | 46 (as v3.1) | 48 (ARP rate and 414 fixed) |
Every version side by side, with the full fault matrix and the standards per requirement: all versions compared.
POWER_ON/OFF/STATUS, OUTx): Companion, eXcontrol, Crestron and Q-SYS work as before. NET_STATUS only gains three fields at the end.