[参考译文] LAUNCHCC3220MODASF：NWP/#39；s 读/写缓冲器的行为

器件型号：LAUNCHCC3220MODASF

您好！

我遇到了使用 ID 为5的 SimpleLinkFatalErrorEventHandler()调用 sl_DEVICE_EVENT_FATAL_CMD_TIMEOUT 的情况。 我有一个 FreeRTOS 线程、当同一套接字上的另一个线程调用 sl_close()时、该线程要么是 MID-sl_Send ()、要么在之后立即调用 sl_Send ()、这与大多数500ms 之后一样。

这应该是有效的主机操作吗？

如果我复位并重复该序列，sl_Send()返回-1，这看起来是正确的行为。 这在 trot 上发生了16次、足以将文件描述符换行至0..15..0。

SlDeviceFatal_t 的六转储是

   05 00 00 10 00 00 00 00 00 00 00 00 。 。 。  .                  

如何解读最后八个字节、即数据 SlDeviceFatalData_u 联合体？ 5的 ID 不是 sl_device_event_fated_no_CMD_ACK 或 sl_device_event_fature_CMD_TIMEOUT、因此 DeviceAssert：

   SlDeviceFatalDeviceAssert_t       DeviceAssert；
   SlDeviceFatalNoCmdAck_t           NoCmdAck；
   SlDeviceFatalCmdlTimeout _t       CmdTimeout；

什么工会会员与什么 ID 对应？

如果它被置为有效、那么代码为0x1010并且值为0。 这是什么意思吗？

谢谢、Ralph。

您好、Ralph、

阻塞 sl_Recv ()仍允许您的 CC3220处于 LPDS 状态、因此您的计划是使用一个线程连接 sl_Recv ()、而使用另一个线程处理 sl_Send ()调用、这是一个好做法。

TX 和 RX 缓冲器是独立的。

我不确定 TLS 压缩的影响，但一般来说，您应该保持 sl_Send()调用较大，以便无线传输的每个数据包都具有有效的有效负载大小。 NWP 将根据需要对 TCP 数据包进行碎片整理。

数据包可能会通过无线方式发送，但这种情况不太可能发生，因为 SL_Send ()被设计为在数据有效载荷缓冲器被发送到 NWP 后立即返回。 因此无需清空 TX 发送队列。

是的，如果 sl_Recv()在其套接字关闭时被阻止，它将返回。

如果您需要进一步澄清或对 CC3220的 NWP 有进一步的疑问、请告诉我。

此致、

Michael

您好、Michael、

谢谢、这非常有用。 自发布以来，我在一个非 TLS TCP 上尝试了两个小型 sl_Send()，并且数据包到达 WLAN 目的地的间隔不到1ms，这与您所说的不需要刷新的情况匹配。

我一直在尝试使用同一 TCP 非 TLS 套接字的两个 FreeRTOS 线程、一个在 sl_Recv ()上循环、另一个 sl_Send ()(频率为2Hz)、第三个线程提供了一个简单的 UART shell、我可以在其中使用 sl_close ()给定的套接字描述符。

我同意、如果作为监听 NC (1)的对等方是 SIGINT、则 sl_Recv ()返回0作为 EOF、sl_Send ()返回-1、sl_error_bSD_SOC_error、这看起来非常好。

如果改为 I sl_close()来自 CC3220 shell 的套接字，则 sl_Send()的行为与以前一样，但 sl_Recv()不返回。 也不会发送 FIN 数据包来启动套接字关断。 NC (1)的 SIGINT 具有其 Linux 发送五个具有指数反转的散热片，但没有回复，并且 sl_Recv ()仍被阻止。 同一套接字的第二个 sl_close()不会返回。

在三次满意的读取之后，另一个测试停止调用 sl_Recv()，但继续以2Hz 的频率调用 sl_Send()。 sl_close()导致没有 FIN，并且主机很快就会锁定，这是通过 sl_Send()错误的 UART 打印来实现的。 一段时间后、它解锁、完成 UART 输出：sl_Send ()返回-1、然后 SimpleLinkFatalErrorEventHandler ()的 UART 输出出现、ID = 5、0x1010和 sl_close ()的返回值为-2005、sl_API_ABLE"、"API has been aborted due to an error by host driver"。

(0x1010上的问题是 https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/909505。)

我重复上述多次、只是预期的 sl_Send 返回-1。 也许这取决于 sl_close()是否在不太合适的时刻发生，而在2Hz 时不太可能发生这种情况。

没有 sl_Shutdown ()来镜像关闭(2)。 这大概意味着我无法在保持套接字打开以供读取的同时触发要发送的 FIN 数据包？

(我意识到 NWP 是具有闭源安全通过防护/深入防御的独立器件是一个优势、但与浏览软件 TCP/IP 堆栈源代码相比、它确实是一个难题。  :-)

谢谢、Ralph。

您好！

我写道：

>如果改为 I sl_close ()来自 CC3220 shell 的套接字、则 sl_Send ()的行为与之前相同、但 sl_Recv ()不返回。 也不会发送 FIN 数据包来启动套接字关断。 NC (1)的 SIGINT 具有其 Linux 发送五个具有指数反转的散热片，但没有回复，并且 sl_Recv ()仍被阻止。 同一套接字的第二个 sl_close()不会返回。

我重复一下。

• SL_Send (0)以2Hz 的频率循环
• SL_Recv (0)被阻止
• SL_CLOSE (0)不返回
• 主机似乎已锁定
• 没有 UART 输出来建议返回 sl_Recv 或 sl_close
• sl_close 未发送 FIN 数据包

如果我然后停止对等设备、它会发送一个 FIN、CC3220 ACK 处于该状态、因此其中的某个设备仍然存在。

谢谢、Ralph。

您好、Ralph、

我合并了您的线程、因为看起来您正在研究相同的调试主题、所有信息似乎都与解决问题相关。 请继续关注此主题。

根据 NWP 本身的时序、在 sl_Send 正在执行时在另一个线程上调用 sl_close 可能会导致 NWP 上出现意外行为、因为它会在您释放套接字描述符后尝试访问套接字描述符。 如果您在多个线程上使用同一套接字、我强烈建议您设置一些应用级保护、以防止这种情况发生。

如果您确实遇到了致命的中止，是否可以调用 sl_Stop()并重新启动 NWP？

此致、

Sarah

您好、Sarah、

我不同意在其他线程具有 NWP 操作的套接字上处理 sl_close()是应用程序的工作。 Michael Reymond 在上面写的“是的，如果 sl_Recv()在其插座关闭时被阻止，它将返回”，除非他误解了我的问题。

NWP 知道关闭时套接字上正在进行的所有操作、并且可以准备所有被阻止的呼叫、以便在下次计划时了解其消失情况。

下面是我尝试处理的情形：我与服务器之间有一个长期的 TCP 连接。 SL_Recv ()在那里很高兴地被阻止了5分钟，并且在这段时间内使用了 LPDS，这是电池寿命所必需的。 本地用户按钮操作意味着必须关闭套接字。 SimpleLink 的 TCP 实施不提供关断功能(2)、因此无法在保持套接字断开的情况下发送 FIN 数据包。 此外，这将假定对等方可以在 sl_Recv()有序展开协作。 我在套接字上调用 sl_close ()、期望所有被阻止的 sl_... 接收呼叫、以便他们可以返回错误、我可以选择忽略这次、因为我知道我关闭了套接字。

我可以改用 sl_Select()，而只使用 sl_Recv()来阻止它，但我认为它在处理 sl_close()时没有更好的选择？

您如何建议主机应用程序尽可能地启用 LPDS、例如、不轮询、在可能希望取消的套接字上进行阻塞？

文档中的何处描述了如何并行处理 NWP 代表主机执行套接字工作？ 我唯一提到的是 sl_Select()，它可以同时从多个线程调用，但需要额外使用一个套接字。

NWP 中的"意外行为"在哪里可能会导致执行并行操作？

我很高兴尝试了解如何满足我的需求、就像大多数程序员一样、我喜欢拼图、但缺少有文件证明的边界 AFICS。

谢谢、Ralph。

我只是想说我同意拉尔夫的情感。  如果在 sl_Send 正在进行时无法调用 sl_close、则需要在某个位置记录这一点。  使用 simplelink 层的库没有针对这种情况的保护、例如 AWS MQTT 库。  

考虑到驾驶员中的各种锁和排队机制、这样做似乎是可以的。   

我可能建议避免使用 SL_Select。  根据您在上面的帖子、我们有类似的要求。  无需轮询即可实现最低的电池寿命。  我们尝试以阻塞的方式使用 SL_Select 它、但发现在同一套接字上调用 sl_close 时不会立即返回。  这是在最终发生某些 WLAN 不良事件并且需要尽快使用新套接字打开新连接时必须执行的操作。  也许这最终在最新的 SDK 中得到了修复、不确定。

我们确实发现、当 sl_recv 被阻止时调用 sl_close 确实会返回 sl_recv。  但有时会使用该奇怪的0xc1010代码。