简介：面向嵌入式与物联网开发者，本工程提供W5500 TCP Server稳定通信的完整参考实现，专门解决网络波动、路由重置或设备休眠导致的连接偶发断开问题，核心采用TCP Keep-Alive心跳机制，适合基于STM32F10x系列MCU配合W5500进行网络通信，以及对实时通信要求较高的远程控制场景开发者借鉴。压缩包为zip格式，共222个文件，约5.68MB，以39个C源文件、45个头文件为主要代码，辅以IAR工程配置、烧录脚本、链接脚本、映射文件以及编译生成的目标文件，可直接导入IAR工程查看和调试。代码中包含自动发送Keep-Alive探测包的服务器端逻辑、TCP控制块中时间间隔/重试次数/超时时间等参数的设置范例，以及连接断开后的检测与优雅关闭流程，能帮助开发者掌握长连接保活的核心要点。已有6557人学习下载，适合远程监控、数据采集等对连接稳定性要求较高的场景。

1. W5500 做 TCP Server 时连接偶尔断开：不是你代码不行，是硬件协议栈的脾气你没摸透

用 W5500 做嵌入式 TCP Server，跑着跑着客户端突然掉线，过一会儿又自己恢复，这是很多开发者踩过的坑。W5500 虽然内置了全硬件 TCP/IP 协议栈，把 TCP 状态机、ARP、IP 校验全给你扛了，但它终究不是一颗无线 SoC，连接稳定性取决于你如何驱动它的 Socket 寄存器，而不是你写了多少逻辑代码。这篇笔记把我拆一个 W5500 TCP Server 工程时的排查过程和修复方案整理出来，从硬件协议栈原理讲到具体的命令序列、重连策略和长时间压力测试，新手能照着改，熟手也能对照检查自己忽略的边界条件。

2. 先把硬件协议栈的脾气摸清：Socket 状态机、寄存器命令与断开的真正原因

2.1 W5500 和纯软件协议栈的本质差异：TCP 状态机在芯片里，不在你 MCU 里

用 LWIP 或者 uIP 做 TCP Server，TCP 状态机是在 MCU 的 RAM 里跑的，你改了代码就改协议栈行为。W5500 不一样，它内部有一块独立的内存（TX/RX Buffer 共 16KB 可配），TCP 的连接建立、确认重传、断线检测全部由芯片内部的硬件逻辑完成。MCU 只通过 SPI 读写寄存器，告诉芯片“你要干什么”，芯片干完了再通过中断或寄存器告诉你“结果如何”。

这个设计的好处是 MCU 负载极低，但坏处也明显：你看不到 TCP 状态机的中间过程。比如对端断电、拔网线、路由器重启，W5500 的硬件状态机可能还停在 ESTABLISHED 状态，直到 TCP Keep-Alive 超时或者你主动发数据触发重传超时，Socket 才被关掉。这就是“有时连接断开”的第一大来源——不是网络真的断了，而是芯片对端感知滞后。

所以排查这一类问题，第一步不是改你的应用层逻辑，而是先确认 W5500 的 Socket 状态寄存器 Sn_SR 当前值是什么。常见状态：

提示:判断连接是否真的断开，不能光靠 Sn_SR，还要看 Sn_IR 里的 DISCON 和 TIMEO 标志，这两个标志位才代表网络层异常。

2.2 断开机理拆解：三种最常见的不稳定场景

我在模拟项目X里复现过 W5500 TCP Server 掉线，归纳下来就这么三类：

第一，对端异常掉电或路由漂移，W5500 收不到 FIN 也收不到 RST，状态机卡在 ESTABLISHED。这种断开是“假死”，客户端重连时因为端口还在 TIME_WAIT 而失败，或者 W5500 的端口被旧连接占着，新连接进不来。

第二，SPI 通信受干扰。W5500 的 SPI 时序其实比较敏感，MCU 主频高、线长、没有做线序约束时，偶发的 SPI 误码会直接写坏 Sn_CR 寄存器，导致 Socket 状态跳飞。现象就是连接在毫无征兆的情况下断开，而且 Sn_SR 读出来是一个非法的中间值。

第三，应用层没有及时处理接收缓冲。W5500 的 RX Buffer 是按块划分的，如果 MCU 读取速度跟不上，芯片的接收缓冲溢出后会静默丢包。对于 TCP 来说，丢包会触发重传，但如果连续丢包导致重传超时，硬件状态机就会直接断开连接。典型的场景是 Server 收到大数据包时没来得及读完，又去 Listen 新的连接，忙不过来就出问题。

这三类问题处理方式完全不同。第一类要靠应用层心跳和重连机制兜底，第二类要靠 SPI 硬件设计和软件校验兜底，第三类要靠合理的 buffer 划分和中断处理逻辑。

3. 重写 TCP Server 核心：从裸奔到带心跳与自动重连的完整实现

3.1 工程整体结构：为什么我不建议用轮询，而是中断 + 状态机

很多 W5500 的 Demo 都是主循环里轮询 Sn_SR，发现不等于 ESTABLISHED 就重新 Listen。这种做法在简单场景能跑，但在长时间运行时会漏掉瞬间状态跳变。我的做法是把 W5500 的中断引脚接到 MCU 的外部中断，Sn_IR 的 DISCON、RECV、TIMEO 标志位触发中断，主循环只做状态处理。

这个工程我分了三个文件：w5500_drv.c 负责 SPI 读写和寄存器操作，tcp_server.c 负责 Socket 状态管理，main.c 里只留一个事件轮询。核心代码如下：

// w5500_drv.c —— WL5500 寄存器读写基础函数 #define W5500_CR 0x001E // 控制寄存器地址 #define W5500_SOCK_REG(sr, off) (0x4000 + (sr * 0x100) + off) // Socket n 寄存器映射 void w5500_write_reg(uint16_t addr, uint8_t data) { uint8_t tx_buf[4]; tx_buf[0] = (addr >> 8) & 0xFF; tx_buf[1] = addr & 0xFF; tx_buf[2] = 0x04; // UDPS=0, RWB=1(写), OM=00(偏移地址模式) tx_buf[3] = data; spi_cs_low(); spi_transfer(tx_buf, 4); spi_cs_high(); } void w5500_write_sn_cr(uint8_t sn, uint8_t cmd) { w5500_write_reg(W5500_SOCK_REG(sn, 0x01), cmd); // Sn_CR 在偏移 0x01 }

这段代码看着简单，但有几个细节决定了稳定性。首先，Sn_CR 的写入必须是在 Socket 空闲状态下才能执行，否则命令会丢失。其次，写入 Sn_CR 之后需要读取 Sn_IR 确认命令完成，大部分情况下还需要读 Sn_SR 判断命令是否生效。很多掉线问题就是因为 Sn_CR 写太快，芯片还没处理完上一个命令就被覆盖了。

3.2 初始化监听流程：LISTEN 命令的正确打开方式

TCP Server 初始化的过程不是简单调一次 socket() 和 bind() 就行。W5500 的 Socket 必须严格按照 “OPEN -> LISTEN -> 等待 ESTABLISHED” 这个顺序来。代码如下：

// tcp_server.c —— Socket 初始化与监听 int tcp_server_open(uint8_t sn, uint16_t port) { // 1. 设置 Socket 协议模式为 TCP w5500_write_reg(W5500_SOCK_REG(sn, 0x00), 0x01); // Sn_MR = TCP // 2. 写本地端口 w5500_write_reg(W5500_SOCK_REG(sn, 0x04), (port >> 8) & 0xFF); w5500_write_reg(W5500_SOCK_REG(sn, 0x05), port & 0xFF); // 3. 发送 OPEN 命令 w5500_write_sn_cr(sn, 0x01); // CMD_OPEN // 4. 等待 Sn_SR 变为 SOCK_INIT if (!w5500_wait_sn_sr(sn, 0x13, 100)) return -1; // 5. 发送 LISTEN 命令 w5500_write_sn_cr(sn, 0x02); // CMD_LISTEN // 6. 等待 Sn_SR 变为 SOCK_LISTEN if (!w5500_wait_sn_sr(sn, 0x14, 100)) return -1; return 0; }

这里有个坑：OPEN 命令执行后必须确认 Sn_SR 等于 SOCK_INIT（0x13），然后再写 LISTEN。如果跳过状态确认，直接发 LISTEN，在 W5500 上偶尔会因为芯片尚未完成初始化而命令丢失，现象就是 listen 失败，但寄存器读出来又不是 CLOSED，而是 0x12 之类的中间态。

参数说明：端口号是高字节在前写进 Sn_PORT[1] 和 Sn_PORT[0]，和常见的小端习惯相反。超时时间我取 100ms，实际项目中如果你的 MCU 主频不高，建议放宽到 200ms，因为 W5500 初始化命令执行需要经过内部 PLL 的时钟周期。

3.3 连接保持与断线检测：心跳包与状态机轮询

连接稳定后，长连接场景下最怕的就是对方掉线了你不知道。W5500 的硬件不提供应用层心跳，你得自己做。我的方案是：MCU 每秒向客户端发一个自定义心跳包，如果连续 3 次发出去没有收到任何回包（不管是心跳回包还是业务数据），就判定连接失效，主动关闭 Socket 重新 Listen。

// tcp_server.c —— 连接轮询与心跳 void tcp_server_poll(uint8_t sn) { uint8_t ir = w5500_read_reg(W5500_SOCK_REG(sn, 0x02)); // Sn_IR if (ir & 0x08) { // DISCON 标志 w5500_write_reg(W5500_SOCK_REG(sn, 0x02), ir); // 清中断标志 tcp_server_close(sn); tcp_server_open(sn, SERVER_PORT); return; } if (ir & 0x04) { // CONNECT 标志（建立成功） w5500_write_reg(W5500_SOCK_REG(sn, 0x02), ir); conn_established = 1; heartbeat_miss = 0; } if (ir & 0x02) { // RECV 标志 w5500_write_reg(W5500_SOCK_REG(sn, 0x02), ir); // 收到任何数据都重置心跳计数 heartbeat_miss = 0; process_rx_packet(sn); } // 心跳发送逻辑：每 1000ms 发一次 if (conn_established && (tick_ms - last_heartbeat >= 1000)) { send_heartbeat(sn); last_heartbeat = tick_ms; heartbeat_miss++; } // 3 次心跳无响应，强制关闭重建 if (heartbeat_miss >= 3) { tcp_server_close(sn); tcp_server_open(sn, SERVER_PORT); } }

这段代码的核心是 Sn_IR 的中断标志位处理。特别注意 DISCON 和 TIMEO 的区别：DISCON 是对端主动断开或网络异常导致芯片检测到断开，TIMEO 是芯片发送数据重传超时。两者清中断标志的时机不一样，DISCON 必须在关闭 Socket 之前清，否则关闭操作会再次触发中断。我踩过这个坑：清标志写在 close 之后，结果 close 产生的状态跳变又置了 DISCON，中断里再调用 close，两个 close 之间寄存器状态错乱，Socket 直接卡死。

3.4 接收与发送缓冲管理：RX Buffer 溢出是隐性杀手

W5500 的 16KB 内存分成 TX Buffer 和 RX Buffer，每个 Socket 可以独立配置大小。默认配置下，RX Buffer 往往是够用的，但如果你开了 4 个 Socket，每个分到 2KB，那一个大的 TCP 分段就可能吃满整个缓冲。

我的建议是 TCP Server 场景只开一个 Socket，把 RX Buffer 配到 8KB，TX Buffer 配到 8KB。如果实在要多路，至少保证 RX Buffer 不小于 4KB，同时把读取数据的逻辑放在中断里第一时间处理，不要积压到主循环。

// w5500_drv.c —— 设置 Socket 接收缓冲区大小 void w5500_set_rx_bufsize(uint8_t sn, uint16_t size) { // Sn_RXBUF_SIZE 在偏移 0x1E，size 是 2KB 的倍数 w5500_write_reg(W5500_SOCK_REG(sn, 0x1E), size / 2048); }

这里注意：Sn_RXBUF_SIZE 的单位是 2KB，寄存器值 0 表示 2KB，8 就是 16KB，总共就这么多。如果你把 RX 配成 4，实际是 8KB，那么 TX 那边的总空间就少了。分配完之后最好读一遍检查是否写进去了，某些早期批次芯片会有寄存器回读异常。

4. 避坑排查：W5500 连接断开的五个高频翻车现场

4.1 翻车 1：芯片是软复位而不是硬复位，状态没清干净

现象：程序重启后，Socket 能 listen 成功但客户端一连接就断开，重复几次后恢复正常。

原因：很多初始化代码只调用了软复位（Sn_MR 的 RST 位）就立刻配置寄存器。W5500 软复位后内部状态机需要等待至少 1ms 才能接受命令，如果复位后马上写 Sn_CR，偶发情况下芯片会丢掉第一条命令。

解决：软复位代码加延时，并在延时后读 Sn_SR 确认所有 Socket 都已到 CLOSED 再继续。我一般加 5ms 延时，宁可慢一点不赌时序。另外，如果软复位后 Socket 状态不是 CLOSED，要做一次硬件复位（拉低 RSTn 引脚至少 500us）。

4.2 翻车 2：中断标志没及时清理，导致中断风暴

现象：连接断开后，MCU 进中断出不来，主循环不跑，看门狗复位。

原因：W5500 的中断标志位是写 1 清零。如果代码里用读寄存器的方式判断中断源，没有正确写入对应的清标志值，同一个中断条件会反复触发。特别是 RECV 中断，如果数据读完但 Sn_IR 的 RECV 位没清，芯片会一直拉高中断引脚。

解决：中断服务函数里第一件事就是读 Sn_IR，处理完对应事件后立即写回读到的值清零。注意不要写 0 去清，W5500 的清中断是“写 1 清 0”，你写 0 等于没写。

4.3 翻车 3：SPI 时钟频率过高，偶发寄存器写错

现象：连接不稳定，时间随机，没有规律，回读 Sn_SR 偶尔出现非法值。

原因：W5500 的 SPI 最高支持几十 MHz，那是理想情况。实际布线长、没有包地、MCU 的 SPI 引脚驱动能力不足时，高频 SPI 误码率会急剧上升。寄存器写错一个位，Socket 状态就可能跳飞。

解决：把 SPI 时钟降到 10MHz 以下。这个芯片又不传输大量数据，低一点完全够用。另外在 SPI 读写后对关键寄存器做一次回读校验，比如 Sn_CR 写了 LISTEN，读回确认再往下走。这种“冗余校验”的代价是每次命令多几十微秒，但稳定性提升是质的飞跃。

4.4 翻车 4：对端掉电后 Socket 进入 CLOSE_WAIT，新连接进不来

现象：客户端设备断电后，Server 端 Socket 状态变成 CLOSE_WAIT，其他客户端连接时一直超时。

原因：W5500 收到对端的 FIN 后进入 CLOSE_WAIT，这是 TCP 正常流程。问题是你的应用层检测到 CLOSE_WAIT 没有主动 close Socket，状态就一直挂着。W5500 没有自动关闭机制，要软件处理。

解决：在状态轮询里加 CLOSE_WAIT 的判断，发现状态等于 0x1C 就执行 DISCON 命令并重新 Listen。代码在 3.2 节基础上加一个 else-if 分支就能处理。

4.5 翻车 5：DHCP 租约到期导致 IP 地址漂移

现象：连接断了之后所有客户端都连不上，但 W5500 看着是正常 Listens 状态。

原因：如果你的工程是 DHCP 动态获取 IP，租约到期后路由器没有续约，W5500 的 IP 地址可能被回收。但因为 TCP Socket 还在 ESTABLISHED 状态，你不读 IP 寄存器根本发现不了。

解决：长连接场景不要用 DHCP，直接写静态 IP。如果必须 DHCP，应用层要额外处理租约告警，或者在心跳超时后强制重新 DHCP。

5. 验证与固化：用连接风暴和断网实验把问题逼出来

改完代码后，需要一套能确实复现问题的验证方案，而不是只靠手动插拔网线。我每次做完这类工程都会执行三个固定测试：连接风暴测试、拔线重连测试、长时运行打点测试。

连接风暴测试的目的，是把 SLISTEN 到 ESTABLISHED 的临界状态转换反复摩擦。原理是 TCP 连接的建立有一个“同时打开”的时序窗口，客户端在连接建立瞬间马上断开，W5500 的状态机会从 ESTABLISHED 跳回 LISTEN。如果 chip 的处理速度跟不上，Sn_CR 的命令就丢。用 PC 上的脚本来做，模拟 100 个虚拟客户端轮流连接并在连接后立刻断开，每轮间隔 50 到 500ms 随机。循环 1000 次，观察 W5500 的 Socket 是否每次都回到 LISTEN 状态。这个测试我一般跑 30 分钟，跑完后看两件事：第一，是否有 Socket 卡在非 CLOSED 非 LISTEN 的中间状态；第二，是否有中断标志位没有及时被清理导致的中断风暴。

# 连接风暴测试脚本（PC 端） import socket import time import random server_addr = ('192.168.1.100', 6000) for i in range(1000): try: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(2) s.connect(server_addr) # 连接建立后立刻发送一个字节，触发 W5500 的 RECV 中断 s.send(b'X') # 随机延时后断开 time.sleep(random.uniform(0.05, 0.5)) s.close() except Exception as e: print(f"Round {i} failed: {e}") raise SystemExit(1) if i % 100 == 0: print(f"Completed {i} rounds") print("Storm test passed: 1000 rounds OK")

这个脚本的关键是随机延时。固定延时是测不出问题的，因为 W5500 的硬件协议栈对周期性命令有“习惯性”响应，随机间隔才能暴露状态机处理速度的边界。还有，每次连接后发送那个字节不是没用的，它让 W5500 进一次 RECV 中断处理，把接收路径的可靠性也覆盖进去。

拔线重连测试则更接近真实故障。脚本打通一条 TCP 长连接到 Server，然后让 PC 断网（禁用网卡）再恢复，重复几十次，观察 Server 端能否在 3 次心跳超时后主动重建连接。这里有个检验点：拔线后客户端进程的 Socket 由于没有数据收发，可能仍然认为自己是连通的，所以要在断网前给客户端设置 TCP_USER_TIMEOUT，否则客户端会一直重传导致 Server 收不到新连接。

最后是长时运行打点测试，本质上是一个压测 + 记录方案。让 W5500 Server 连续运行 72 小时，MCU 每 30 秒通过串口打印一次当前 Socket 状态和 Uptime，PC 端脚本每 10 秒发一个业务数据包。跑完分析日志，重点看两个指标：Socket 状态跳变次数和连接重建次数。如果 72 小时内重建次数为 0，说明这段代码可以交出去了；如果有个位数的重建，说明心跳阈值或超时时间还需要调。这个测试跑完，基本能把论文里没写的边界问题全部逼出来。

从那以后，我每写完一个 W5500 长连接程序，都会强制自己走一遍这三道测试再发布，连接风暴、拔线重连、72 小时打点，一次都不省。不是因为不信任改动，而是这种“偶尔断开”的问题，它最大的危险就是不可复现，不可复现就意味着后面随时会在现场再来一次。希望这篇笔记帮你少走一段弯路。

本文还有配套的精品资源，点击获取