ESP32 Forum

我最近使用ESP32C5-MINI1U这个模块做了一个项目，ESP-AT工程按照官方的硬件连接建议，（不同之处是我未使用硬件流控），软件使用了github上的master分支本地编译，之后使用at.py修改了波特率为4000000,关闭流控引脚，使用flashdowntool下载成功。
软件部分参考了示例“ESP32-C5 设备作为 TCP 服务器，实现 UART Wi-Fi 透传”的步骤：
AT+CWMODE=1，设置 Wi-Fi 模式为 station。
AT+CWJAP=XXX，XXX，连接到路由器。
AT+CIPMUX=1，TCP 服务器必须在多连接模式下才能开启，
AT+CIPSERVERMAXCONN=1，设置 TCP 服务器最大连接数为 1。
AT+CIPSERVER=1,8080，开启 TCP 服务器。
PC客户端连接之后，进入 UART Wi-Fi 透传接收模式。
AT+CIPMODE=1，进入 UART Wi-Fi 透传模式 并发送数据。
AT+CIPSEND，>进入透传模式。
遇到的问题：
PC发送启动命令后，MCU按照100HZ, 1360字节／包的速度发送数据，刚开始一切都正常，但连续发送30分钟数据后，PC端再也收不到数据，此时能够接收到PC发送来的数据。PC端断开连接，重新连接TCP服务器，也是只能PC到MCU方向正常，但MCU发出的数据无法传递到PC。

尝试的办法：１.打开AT工程的TCP调试功能，Debug信息未发现TCP连接断开；
２.打开AT工程的UART调试功能，但由于Debug口未修改波特率程序会卡死；
３.增加KeepAlive功能；
４.增加AT+CIPSTO超时功能；未能解决问题
５.降低串口波特率至2M,现象依然存在。

问题：１.是否因为采用了过高的波特率，且未使用硬件流控造成？建议的最高串口波特率是多少合适？
２.如何能够监测到透传的异常？目前发生异常后没有任何提示输出，如果有错误提示的话，可以重新复位WIFI模块以及TCP透传连接。
３.如何进一步排查此问题，找到解决问题的方向？
希望有人能够解答，非常感谢！

在英文的论坛里，找到相关的一个话题，但是也没有最终的解决方案：
[ESP32 AT Firmware] Module Stops Responding After Several Hours of Stable Operation
viewtopic.php?t=46273

经过不断的尝试，终于发现了我的问题所在。
主要的原因可能有两个：
1是默认的发送BUFFER太小，这一点需要修改LwIP库和WiFi配置里面的参数，增加TXBUFFER的大小；
2是我在使用了AT+CIPTCPOPT这个命令时，将SO_SNDTIMEO 这个参数设置为了10，注意这个单位是毫秒，按照文档推荐的值应该是5000-10000才对。
详细的说明： SO_SNDTIMEO 选项适用于 AT+CIPSTART 命令未配置 keepalive 参数的应用场景。配置本选项后，AT+CIPSEND、AT+CIPSENDL、AT+CIPSENDEX 命令将会在该超时内退出，无论是否发送成功。这里，SO_SNDTIMEO 建议配置为 5 ~ 10 秒。
好了，这个问题暂时告一段落，可以继续搞下去了。

修改完上述配置参数后，该问题仍然会复现，通过对比数据包，发现串口发送的数据包要比WIFI客户端接收到的多，也就是说，可能WIFI透传程序存在数据堆积的现象，一旦堆积的数据包超过一定的数量，就会导致透传程序的发送功能卡住。目前4M的串口波特率的确较高，但也在模块的设置参数范围内（最高可设置到5M波特率）。是否只有加上串口的硬件流控才能解决这个问题呢？

更新了最新的AT工程v5.0.0.0版本，貌似没有这个问题了，测试了3个小时，没有中断。

@netbeans2006 要是想不丢数据，一定得开 UART 硬件流控。因为在网络波动的情况下，只要 ESP32-C5 的 UART 接收速度大于网络发送的速度，就可能出现 UART buffer 满，从而丢数据。

4Mbps 是个相对较高的 UART 波特率，需要您的上位机本身能很好的支持这么高的速率，且和 ESP32-C5 之前的连接线尽可能短。否则数据本身可能会出错。如果想要高的吞吐，也可以使用 SDIO 和上位机通信。

进入透传模式前，可以发送 AT+SYSMSG=7，监控透传模式下的一些系统状态变化。

感谢回复，目前确实在网络信号不好的情况下会有数据丢失的问题，但没有断开透传的问题了，结果能够接受。下一版本我再考虑硬件流控的修改吧，主控用了STM32的H7单片机，C5模块的AT工程在4M波特率下也能够正常工作，满足我的使用需求。

感谢您对乐鑫产品和 AT 方案的关注！