This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC3220MOD:WiFi 发送但未接收

Guru**** 2553260 points
Other Parts Discussed in Thread: CC3220SF

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/656177/cc3220mod-wifi-transmits-but-does-not-receive

器件型号:CC3220MOD
主题中讨论的其他器件:CC3220SF

我已经对 CC3220SF 模块进行了编程、该模块使用 UDP 消息通过 WiFi 与服务器设备进行来回通信。  不过、有时我会遇到 CC3220发送但无法接收的情况。  在这种情况下、我可以看到服务器接收到 CC3220发送的消息、但当服务器立即回复 sl_Recvfrom (..)时 对 CC3220的调用永不返回任何数据-它始终返回 SL_ERROR_BSD_EWOULDBLOCK。  同时、我还拥有 CC3220的对等器件、它们能够与服务器进行来回通信、而不会出现任何问题。

在我更改 CC3220的 IP 地址(每个器件使用静态 IP)后、问题似乎最频繁发生;如果我对器件进行下电上电、它会在重启后立即开始工作。  如果我碰巧在调试器中、并在一个断点处停止以检查变量状态、那么在我恢复后、它将立即开始工作。  我还在一些设备上添加了代码、用于检测2分钟后是否未收到任何数据、然后重新初始化所有 WiFi 配置、这似乎也使其再次正常工作。  但是、即使在没有此代码的器件上、似乎有时它们最终会自行开始工作(可能为10分钟、可能为1小时...)。

一些附加说明:

  • CC3220SF 模块以"会话"模式运行。  它们连接到我的"服务器"应用程序也连接到的接入点。
  • 所有 CC3220套接字操作均配置为非阻塞。
  • 我的 CC3220应用在没有任何 RTOS 的情况下运行。
  • 我将在 每个 CC3220模块上安装服务包 sp_3.5.0.0_2.0.0.0_2.2.0.5.bin。
  • 我看到一些帖子表明调用 sl_Recvfrom (..)是个问题 频率过高、但这似乎是通过使用稍后的 SDK v1.50来解决的、我想我已经使用了该版本。

 是否有任何关于尝试什么的建议?

谢谢、

AJ

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、AJ、

    您能不能帮助我理解您提到"更改 CC3220的 IP 地址(每个器件使用静态 IP)后、问题似乎最频繁发生。" 如果设备使用静态 IP 地址,则 IP 地址如何更改?

    此外、对于没有具有非阻塞套接字操作的 RTOS 应用程序、返回值 SL_ERROR_BSD_EWOULDBLOCK = SL_ERROR_BSD_EAGAIN 意味着未接收到数据、您应重试。 请记住、UDP 是一种无连接协议、这意味着可能存在数据包丢失、错误插入、误送、复制或序列外传输。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    很抱歉造成混淆。  我的每个基于 CC3220的器件都会获得一个唯一的"机器号"(每个器件都有一个关联的触摸屏)、并且根据该机器号、我们的代码会使用静态 IP 地址配置 CC3220。  我们不使用 DHCP。  我的经验是、如果我将"机器编号"更改为其他(但仍然是唯一的)值、因此我的代码会更新静态 IP 地址、那么这个问题似乎更有可能发生(但并非总是如此)。

    今天上午、我们继续使用无线数据包监听器进行调查、看起来我们的器件会将其 UDP 消息发送到服务器。  服务器尝试回复、但首先发出 ARP 请求;看起来 CC3220不响应此 ARP 请求。  因此、从服务器返回的响应实际上永远不会被传输。

    我在 e2e.ti.com/.../439534上发现 了另一位用户说他看到了类似的问题、并通过将 WLAN 电源管理策略配置为"始终开启"来解决这些问题。  但是、这不是 TI 的官方回复-因此我有兴趣了解这是否是已知问题?

    谢谢、

    AJ

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    你好、AJ、

    关于被忽略的 ARP 请求,您的应用程序是否使用 LSI?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    没有意识。 在我的应用中、我希望我的器件能够持续通信、功耗不是问题。 到今天为止、我一直将电源管理策略设置为正常、但这只是因为示例代码就是这样做的。 现在、我在手册中更多地研究了此设置、我认为始终开启是适合我的应用的设置。 我只想知道我是否应该期待这可能会导致我看到的问题。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    你好、AJ、

    是的、我希望始终打开以解决被忽略的 ARP 请求问题。