[参考译文] CC3100MODBOOST：收发器模式下 TxPoolCnt 耗尽

您好！

请查看我 的旧版线程 或 具有驱动程序修复的此线程。

1月

感谢您在1月的快速响应  我已经在具有驱动程序修复的线程中指定的 TxPoolCnt 操作周围实施了锁定、但这并不能解决问题。

TxPoolCnt 值直接来自_SlDrvMsgRad()中的 CC3100。  不释放缓冲区的是部件本身。 即使我坐下来等待他们已经用尽，他们似乎也不会获释。

当 CC3100处于此状态时、我是否需要对其执行某种轮询？

您好！

很抱歉、这是很久以前了、我不记得这个问题的所有内容。 我无法说出上面这些线程中所述的更多信息。

1月

啊。  我之前曾多次阅读过您的旧主题、但其中一些消息是隐藏的。  现在，我看到您实现 WLANTxPoolProtection了()，以便在池计数低于15时检查池计数和延迟。  它还会在超时时返回错误、以便您可以关闭套接字。

有几个问题、因为没有更多详细信息：

1.延误是否足以解决主要问题？

2.关闭套接字(超时)并打开新套接字的频率如何？

3.关闭套接字时、您是刚刚打开了一个新套接字、还是还需要重置 CC3100？

您好！

回答您的问题。

1.延误是否足以解决主要问题？

在我的案例中、它运行良好。 但老实说、我不再使用 CC3200。 我已将设计迁移到可用的 CC3220、因为它比 CC3200要好得多。

2.关闭套接字(超时)并打开新套接字的频率如何？

我不确定您的问题。 如果你问我这个问题的频率、我记得这种情况很少见。 我主要在负载测试期间看到这个问题、如果信号很差。 让我们假设在通过 CC3200传输数百 GB 数据的过程中、每2-3天大约传输1次数据。

3.关闭套接字时、您是刚刚打开了一个新套接字、还是还需要重置 CC3100？

如果出现问题、则必须重新启动 NWP (sl_Stop（)、sl_Start（))、但如果不允许将 TXPool 降低到15以下、则足够等待片刻、之后继续发送。

1月

嗯。  这并不是特别有用。

 WLANTxPoolProtection我将 flow_cont_min 从1更改为15、而不是实现我自己的()版本。  这样就可以正确完成流量控制、任何等待都将使用 OS 基元而不是100ms 延迟循环来完成。  虽然在达到15的 TxPoolCnt 时有足够的延迟、但它没有解决这个问题。

最初、我的代码中的一个错误是重复发送多个1472字节的数据包、直到池计数耗尽。  它不会恢复。  我修复了我的发送代码、现在我每隔大约只发送36个字节、我仍然可以看到池计数下降、没有任何恢复迹象。

Jan 非常感谢您的回复、但如何获取有关此 CC3100产品的官方支持？

尊敬的 Patrick：

您能否收集 NWP 日志？

此致、

Sarah

好的。  我连接到 CC3100MODBOOST 原理图上标记为 CC_NWP_UART_TX 的引脚(板上标记为 NWP)、并按规定设置串行端口。  二进制日志涵盖从复位到 TxPoolCnt 达到15的时间周期(3 - 4分钟)、该时间与我为 flow_CONT_MIN 设置的值相匹配。  此时、我的传输停止、因为 TxPoolCnt 不会增加到超过16。  我每5秒传输36个字节。

e2e.ti.com/.../nwp1.log

谢谢 Patrick！ 我将查看日志并查看我们可以重新创建的内容。 我将在星期五向您提供最新信息。

此致、

Sarah

尊敬的 Patrick：

您使用哪些参数来打开套接字？

我看到很多 socket_TXFAILEDASYNCRESPONSE、看起来您是在不断地向遇到错误的套接字发送数据、并且无法发送缓冲数据。 您是否在套接字回调中看到此错误？ 关闭插槽应该可以释放内存、我们可以深入了解插槽出现故障的原因。

使用我们本周发布的最新服务包进行测试也可能很有用。 可能会有影响套接字行为的更改： http://www.ti.com/tool/download/CC3200SDK

此致、

Sarah

我正在通过以下调用打开套接字：

      eSocket = sl_Socket (sl_AF_RF、sl_sock_raw、0)；

当我执行36个字节的 send()时，我得到的返回值为36，表示发送成功。

通过套接字回调、您是否指的是 sl_sockEvtHdlr ()？  我目前没有连接它、但现在将连接它。

SOCKET_TXFAILEDASINCRESPONSE 的具体含义是什么？为什么会发生这种情况？

在连接套接字事件处理程序的情况下、我现在在尝试以收发器模式发送时获得该事件：

CC3100 0套接字 TX 失败事件 SD：128状态：-116

尊敬的 Patrick：

sl_Send 的返回值验证到 NWP 的传输是否成功。 -116是否是您在 sl_sockEvtHdlr 上获得的第一个错误？ 您是否继续发送并稍后看到其他错误？

您能否使用最新的 servicepack 1.0.1.131-2.12.2.8进行测试并捕获 NWP 日志？

此致、

Sarah

是的、这是我得到的第一个错误、也是我以后看到的唯一错误值。

您能否提供指向2.12.2.8 NWP 下载的链接？  我在 SDK 下载页面()和主页(processors.wiki.ti.com/.../CC3100_&_CC3200)上都没有看到它。

您好、Sarah、我很乐意尝试更新版本的 NWP 固件。  我可以从何处下载它？  CC3100支持页面都显示为锁定状态、且已有很长一段时间未更新。

尊敬的 Patrick：

最新的服务包(1.0.1.14-2.12.2.8)可从 CC3100 SDK 下载页面获取。

1月

2.12.2.8似乎没有什么不同。  下面附上 NWP 日志。

问题： 我在收发器模式下运行(LVL1 =sl_sock_raw)、因此我假设发送的数据格式没有要求。  这是一个错误的假设吗？  TX 套接字错误事件的原因是否是正在检查数据？

e2e.ti.com/.../nwp4.log

您好 Sarah、我在第24页发布的 NWP 日志是否有助于缩小 TX 误差的原因？  此外、您能否在上一帖子中评论我的问题？

似乎我的问题是我将 sl_Send()的 flags 参数设置为零。  根据文档、可以将此参数设置为零、但这是我得到 TX 误差的时候。

现在、我要设置 CHANNEL = 11、RATE = 11M、Power = 1、Preamble = 1、我不会得到相同的误差。  需要以下哪些设置？  我是否可以将它们中的任何一个设置为零、以便它们不会覆盖默认值？  文件不清楚。  我不想覆盖每次发送时的套接字参数(通道、速率、功率或前导码)。

尊敬的 Patrick：

对拖延表示歉意。 我们跟踪了-116误差的来源、这是由于没有可用的 PHY 参数。

似乎没有为收发器模式设置内部默认值、因此您正处于正轨。 是否可以尝试 先使用 sl_SetSockOpt ()设置所有这些参数？ 设置后、您应该能够像以前那样使用 sl_Send 将参数默认为这些参数。

此致、

Sarah

尊敬的 Patrick：

我们的新一代器件似乎已更新文档、但 CC3100未更新。 我将为此提出请求。

此致、

Sarah