[参考译文] CC3100：CC3100停止传递传入的数据包

我在日志中看不到任何问题。

我可以看到它是 UDP 会话。

在被卡住之前收到了多少个数据包？

是否确定要向设备发送数据包？

您是否正在使用块套接字？ 什么是 RX 超时？

正确、这些是 UDP 广播包。

我认为、测试之间的数据包数量各不相同。  您知道这一点有多重要？  我可以添加一些代码来对数据包进行计数并进行报告。

是的、我确定数据包在网络上。  如果我使用 CC3100s 运行两个电路板、一个电路板通常会在另一个电路板停止后继续接收数据包。

我重复执行 sl_Recvfrom ()。  此 API 没有可用的超时参数。

我希望接收到的数据包数量与日志中的活动进行比较(可能会找到一些内容)。 但是、正如您提到过的、您没有使用超时、我知道只有最后一个 sl_Recvfrom 卡住了。

下面是用于定义接收超时(对于阻塞套接字)的 API。  

i16 Status;
struct SlTimeval_t TimeVal;
TimeVal.tv_sec = 5; // Seconds
TimeVal.tv_usec = 0; // Microseconds. 10000 microseconds resolution
Status = sl_SetSockOpt(Sd,SL_SOL_SOCKET,SL_SO_RCVTIMEO, (_u8 *)&TimeVal, sizeof(TimeVal));

感谢这个示例。  我添加了一个5秒的接收超时，但当问题发生时 sl_Recvfrom ()似乎不会返回。

在该超时到位后、我记录了这个新的 NWP 调试输出(如下所示)。  我在它停止前收到了220个数据包。

e2e.ti.com/.../cc3100_2D00_nwpdebug2.zip

在这个新的 NWP 日志中、我只能看到一个 sl_Sendto、而没有 sl_Recvfrom。

您的系统与通过 sl_Recvfrom 调用循环的线程并行执行什么操作？

在 RX 卡住的情况下(使用看门狗驱动程序或使用软件逻辑)，是否可以使用看门狗机制？ 发生这种情况时、您是否尝试重置 NWP (SL_Stop+SL_Start)？  

您是否尝试在 sl_Recvfrom 之间添加延迟？

发生这种情况时、是否会发生异常异步(错误)事件？

最新的 SP 版本为2.14 ( https://www.ti.com/tool/download/CC3100SDK 中提供)-请尝试使用此版本。

奇怪。  也许我没有正确收集 NWP 调试数据。

由于这是一个完全多线程的嵌入式系统、CPU 正在并行执行许多操作。

否、发生这种情况时未收到异步错误。

接下来的几天我将详细介绍您的建议：出现问题时看门狗复位、在 sl_RecfFrom ()之间添加延迟以及使用 SP 2.14。  我会告诉您我找到的内容。

好的。 我将等待您 的响应。

至少有两种故障情况。  其中一种情况是、当中断接收时、我会立即收到中止事件：

CC3100中止事件。 类型：2数据：865
CC3100套接字错误未知：-4

在另一个模式中、sl_Recvfrom ()被调用、但绝不返回(即使是5秒的套接字超时也是如此。)

我尝试在对 sl_Recvfrom 的调用之间添加延迟(最长100ms)、但这并没有什么不同。

我还升级到了2.14.0.0 Service Pack、没有看到任何变化。

我仍在研究 RX 看门狗建议、但这似乎更像是带辅助。

您能否提供更多 NWP 日志？

至少应在日志中显示中止情况。