您好，你的数据包里面还有DHCP协议数据包的收发，直接连PC的时候需要关闭DHCP的使能。

你好，我这个问题解决了，是复位脚的问题，谢谢

你好，我描述一下我的问题，我这边采用CH395Q，8个socket全部使用，其中7个作为UDP客户端，一个作为TCP客户端；

出现的现象呢是：之前8个socket一起打开时会出现程序运行期间突然收到一个Tcp Connect 中断，然后某socket突然接受到大量数据（大量ffff），然后所有的socket状态就变成了ff，

起初我以为是TCP socket的问题，然后我将TCPsocket代码屏蔽后依然会出现这个问题。经过数分钟后，可以自动恢复，不清楚是什么原因。

您好，先确定开启的8个socket能正常通信。程序默认分配4个socket的量，使用8个socket需要重新分配缓冲区。

缓冲区我是重新分配了的

您好，相关问题可联系我司网络产品线技术支持，可以详述问问题情况。/services/technical_support.html 

我们使用CH395Q和W5500进行背板以太网通信（无变压器，通过0.1uF电容耦合），现在上电会偶发二者无法通信，重新掉电之后又好了，请问可能是什么原因？另外贵司的电话技术支持也太拉跨了，换了几个人感觉就没一个懂的，就在那儿沉默，敷衍，不解决问题也不提供思路，真的气。

工程师您好，首先对您不愉快的咨询过程深表歉意，不论是您方的期望还是我司方的目的都会以解决客户问题为首要，希望能您能多支持。我们接受对产品不足上的批评，但同时希望之后在电话咨询的过程中减少对公司、产品及通话人的骂责行为，能在通话过程中提供有效的问题信息。

以下是想对一些问题进行询问

（1）是否经过调试测试，对两颗芯片哪一方存在的问题（鉴于您在另外一个帖子中说的是插座链接，大致上可以交换两端芯片           板的种类进行测试）。

（2）以太网通信不上，是指物理层Link不上，还是指传输层的通信收发问题（包括使用UDP无法发送或是TCP模式下无法握手           成功），可以详述问题状况。

（3)  您说的上电偶发“二者无法通信的状况”是指如果上电后能通信便一直正常，上电后不正常就无法恢复的现象吗？

（4）您直接用的背板通信，虽然相对来说是小负载驱动，但还是除了必需的耦合电容之外还是在收发线路上加上上拉，以增强           稳定的驱动性。

（5）您使用的FPGA进行驱动，还是希望提供能反映运行过程的信息，比如FPGA驱动CH395出问题时状态机的状态位，和读             取到的CH395本身的运行状态信息。

（6）上电“偶发二者无法通信”现象，是否此次上电前保持过较长时间掉电状态？

通过您的描述，出问题的情况基本固定在上电时刻（即假设上述第 2 项成立），在此状况下提供的假设建议：

（1）网络口通过50cm的传输线进行传输此前没有做过相关的验证，鉴于您之前在其他帖子下的发问，可能的问题可以看一               下： /bbs/thread-65673-1.html  的帖子。

（2）芯片启动时刻整个通信线路上的信号循环反射程度基本上是最强的时刻，并且电源线上的电压振铃会增加芯片启动的不稳

         定性

（3）信号线下层和两边都要尽量铺地，两边地上并排打上过孔

（4）中间加上的电容主要是隔直作用，但若两者本身的交流信号存在差异，0.1uF不是固定值，可以依据实际带宽进行优化             （鉴于正常传输下始终正常传输，很可能还是上启动存在问题），可以适当降低电容值，或者在电容旁并联兆欧电阻或者              串联小几十欧姆左右电阻）。

  在目前您有的通信板的情况下，建议做的测试项：

（1）可以交换两端芯片板的种类进行测试（CH395与CH395，CH395与W5500，W5500与W5500）

（2）监测 INT RSTI SEL等重要功能脚上电前后的电平位，查看正常不正常时是否有明显的分别。

（2）尝试给CH395与其FPGA主控和W5500及其FPGA主控先后上电（可改变上电的先后顺序），看是否减少甚至不复现异常           的概率。

（3）尝试增加各CH395Q电源周围和主电源输入的滤波电容的电容值

（4）监测出现异常状况时候CH395芯片的晶振的起振状态

（5）如果信号线上未接电阻上拉，建议飞线尝试

CH395 TCP服务器端，在传输过程中断开连接的问题：

将CH395配置成主机端模式，并发送数据，在发送过程中，会出现断开连接的问题，用CMD_GET_INT_STATUS_SN获取状态，获取到值为SINT_STAT_DISCONNECT （socket断开状态）。

现在按照讨论区的方法，进行重连，如果直接按照open socket 再监听的步骤，会出现1B（已被使用）或者17（连接关闭）的问题。

现在想咨询遇到该问题的解决步骤和问题排查方法.

（1）可能是接收线程调度的问题。由于其他线程在某时刻的占用导致对端发送的数据无法及时接收。

（2）主要可能是数据接收的后处理导致。可以屏蔽处理代码，单纯的接收测试，如测试后确定与接收后处理有关，请对处理项

         逐一调试。

技术支持你好，请问可以提供一份使用STM32的SPI接口驱动CH395的例程吗？最好是使用FREERTOS系统的。

谢谢。

您好，只有裸机程序，暂无操作系统。已发送至您邮箱。

谢谢

您好，我用CH395Q的socket1发送UDP数据，电脑一直无法收到，而socket中断一直回馈数据为0x41，根据手册描述，是空闲以及超时中断？超时中断是怎么产生的？我电脑的IP和端口设置都正确。

您好，UDP协议下第一包数据可能因为为存在ARP而发送失败，需要在超时终端里补发。