[参考译文] LAUNCHCC3220MODASF：WiFi 在几秒钟/分钟后断开

您好！

我还有另外两个 NWP 文件。 在这些情况下、客户端仍处于阻塞式读取调用中、SimpleLinkWlanEventHandler 回调的时间非常晚。

可能是同一个问题。 一些其他线程正在工作、RTOS 堆栈和堆检查告诉我一切正常。

非常感谢
Roman Jordane2e.ti.com/.../timod_5F00_nwp.tar.gz

大家好、

为了完成此操作、我从 tcpEcho 示例中附加了 NWP 日志。 几秒钟后连接中断。

首先我执行 ping 操作、然后我启动了 tcpEcho paython 脚本。

非常感谢、
罗马

e2e.ti.com/.../timod_5F00_tcpEchoFailed.cap.tar.gz

您好、Roman、

您捕获的 NWP 日志似乎已损坏。 请确保您具有此处所述的正确捕获设置：

http://processors.wiki.ti.com/index.php/CC3120_%26_CC3220_Capture_NWP_Logs

另请尝试将 CC3220设置为始终开启模式、并查看您是否遇到相同的问题。 您可以使用 sl_WlanPolicySet (sl_WLAN_policy_PM、sl_WLAN_Aways_on_policy、NULL、0)；API 来执行此操作。 让我知道使用常开模式是否会改变任何东西。

此致、

Michael

您好、Michael、

非常感谢您的回答。

用于捕获 I used  minicom -D /dev/ttyUSB0 -b 921600 -H -w -C timod01.ca p 也许微型计算机会更改一些值。 如何才能看到捕获的数据格式正确？

在我第二次写邮件并在 TI 论坛中搜索之后、我找到了有关 sl_WlanPolicySet (sl_WLAN_policy_PM、sl_WLAN_Aways_on_policy、NULL、0)的信息。 我在设置/检查 WiFi 角色后将此调用插入 platform.c。 该调用返回0。

我仍在测试。 但我可以说、现在的运行情况要好得多。 断开连接的次数要少得多。

我会随时通知您。

非常感谢、
罗马

您好、Roman、

在捕获的日志中、如果要使用文本编辑器打开原始二进制日志、则应可以看到 ASCII 格式的一些纯文本文件名。 例如、在引导时、器件应从/sys/servicepack.ucf 上的外部串行闪存文件中读取 servicepack、并且该文件名将显示在日志中。

再看一下日志、二进制数据似乎是以 ASCII 十六进制字符串的形式保存的、而不是我的日志解码器工具所期望的原始二进制文件。 如果在 minicom 中删除-H 选项并重新捕获日志、会发生什么情况？

此致、

Michael

尊敬的 Michaele2e.ti.com/.../7608.minicom.cap.tar.gz：

我使用以下命令捕获了该 文件：Minicom -D /dev/ttyUSB0 -b 921600 -C minicom.cap 并将该文件附加到此条目。
不幸的是、我无法重现故障。 但我想知道格式现在是否正确。

对于此测试、我禁用了 sl_WlanPolicySet (sl_WLAN_policy_PM、SL_WLAN_Aways_on_policy、NULL、0)；。 结构 SimpleLinkWifiCC32XX_config 中的 WiFi 策略设置为 SL_WLAN_Aways_on_policy (就像我断开连接时一样)。

非常感谢、
罗马

您好、Michael、

我有第二次捕获、也没有失败、但有不同类型的捕获。

stty -F /dev/ttyUSB0 921600 cs8 cread -cstopb raw
Cat /dev/ttyUSB0 | TEE ttylog.cap

请检查格式是否正确。

e2e.ti.com/.../ttylog.cap.tar.gz

非常感谢、
罗马