简介面向嵌入式与物联网开发者本工程提供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 ServerTCP 状态机是在 MCU 的 RAM 里跑的你改了代码就改协议栈行为。W5500 不一样它内部有一块独立的内存TX/RX Buffer 共 16KB 可配TCP 的连接建立、确认重传、断线检测全部由芯片内部的硬件逻辑完成。MCU 只通过 SPI 读写寄存器告诉芯片“你要干什么”芯片干完了再通过中断或寄存器告诉你“结果如何”。这个设计的好处是 MCU 负载极低但坏处也明显你看不到 TCP 状态机的中间过程。比如对端断电、拔网线、路由器重启W5500 的硬件状态机可能还停在 ESTABLISHED 状态直到 TCP Keep-Alive 超时或者你主动发数据触发重传超时Socket 才被关掉。这就是“有时连接断开”的第一大来源——不是网络真的断了而是芯片对端感知滞后。所以排查这一类问题第一步不是改你的应用层逻辑而是先确认 W5500 的 Socket 状态寄存器 Sn_SR 当前值是什么。常见状态Sn_SR 值状态宏含义常见触发场景0x00SOCK_CLOSED关闭主动 close 或对端 RST0x13SOCK_INIT初始化完成open 命令执行后0x14SOCK_LISTEN监听中listen 命令执行后0x17SOCK_ESTABLISHED连接建立accept 成功后0x1CSOCK_CLOSE_WAIT对端已关闭等待本地关闭对端发送 FIN提示:判断连接是否真的断开不能光靠 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; // UDPS0, RWB1(写), OM00(偏移地址模式) 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_INIT0x13然后再写 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 配到 8KBTX Buffer 配到 8KB。如果实在要多路至少保证 RX Buffer 不小于 4KB同时把读取数据的逻辑放在中断里第一时间处理不要积压到主循环。// w5500_drv.c —— 设置 Socket 接收缓冲区大小 void w5500_set_rx_bufsize(uint8_t sn, uint16_t size) { // Sn_RXBUF_SIZE 在偏移 0x1Esize 是 2KB 的倍数 w5500_write_reg(W5500_SOCK_REG(sn, 0x1E), size / 2048); }这里注意Sn_RXBUF_SIZE 的单位是 2KB寄存器值 0 表示 2KB8 就是 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 翻车 3SPI 时钟频率过高偶发寄存器写错现象连接不稳定时间随机没有规律回读 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 翻车 5DHCP 租约到期导致 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(bX) # 随机延时后断开 time.sleep(random.uniform(0.05, 0.5)) s.close() except Exception as e: print(fRound {i} failed: {e}) raise SystemExit(1) if i % 100 0: print(fCompleted {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 状态和 UptimePC 端脚本每 10 秒发一个业务数据包。跑完分析日志重点看两个指标Socket 状态跳变次数和连接重建次数。如果 72 小时内重建次数为 0说明这段代码可以交出去了如果有个位数的重建说明心跳阈值或超时时间还需要调。这个测试跑完基本能把论文里没写的边界问题全部逼出来。从那以后我每写完一个 W5500 长连接程序都会强制自己走一遍这三道测试再发布连接风暴、拔线重连、72 小时打点一次都不省。不是因为不信任改动而是这种“偶尔断开”的问题它最大的危险就是不可复现不可复现就意味着后面随时会在现场再来一次。希望这篇笔记帮你少走一段弯路。本文还有配套的精品资源点击获取
