[参考译文] CC3200：CC3200 Wifi 关闭调试

您好、Kris、

在这种情况下，从 sl_DevGet()读取值不会有多大用处。 调试此类问题的最佳方法是捕获 NWP 日志( 参见 swru368的第19章)并通过 WiFi 监听器捕获 WLAN 通信。

1月

您好、Jan、感谢您的快速回答！ 我很高兴这样做、但我的客户已将 UART1引脚分配出去。 您能将输出重新路由到 UART1吗？

校正- UART2在该板上已输出引脚

您好、Kris、

我不确定 NWP 日志是否可以映射到 CC3200的其他引脚。 我知道 NWP LOG 引脚可以重新映射到 CC3220器件的其他一些引脚、但我不确定 CC3200。 如果 CC3200上有重新映射引脚的选项、请等待 TI 的回答。

借助 CC3220、您可以选择：

• MAP_PinTypeUART (PIN_53、PIN_MODE_5)；//GPIO30
• MAP_PinTypeUART (PIN_18、PIN_MODE_3)；//GPIO28
• MAP_PinTypeUART (PIN_60、PIN_MODE_3)；//GPIO5
• MAP_PinTypeUART (PIN_62、PIN_MODE_1)；//GPIO7

1月

我也没有 CC3200的 NWP 记录器多路复用信息。 查找合适的联系人需要几天时间。

我想您可以尝试 CC220多路复用选项。

 在信道6上配置的 Amazon Eero 路由器是否也是如此？

您能否控制 Eero 信道？ 您能否验证冲突是否发生在其他通道上？

当 CC3200停止广播  其信标时-它是临时的吗？ (即、它将在一段时间后恢复？ 如果是-有多长时间？)  

您好、Kobi、

没问题。 请在引脚复用信息可用时告知我。

Amazon Eero 路由器是消费者简化的设备、不允许或指示他们当前使用的信道。 实际上、他们知道动态更改它们、因此很难假设问题发生时是否在通道6上运行。 我猜可能是以某种形式使用通道6、但没有数据来备份该理论。

当它停止广播时、它保持关闭状态、直到执行 sl_stop 和 sl_start 或器件复位。

此致、

Kris

您是否从 NWP 收到任何异步(错误)事件？

您使用的是什么 SP？

您好、Kobi、

感谢你的答复。 对于 NWP、我尚未对其是否可与 UART2/引脚分配更改搭配使用的待处理信息执行任何操作。 这是不是我可以在不流式传输数据的情况下执行的操作吗？

这使用的是 CC3200SDK v1.5.0和 TIRTOS 2.16.00.08

此致、

Kris

安装了哪个版本的 NWP Service Pack？ (必须安装 Service Pack)。

我询问的信息 来自主机(异步事件 可能在 SimpleLinkGeneralEventHandler、  SimpleLinkFatalErrorEventHandler 或 SimpleLinkWlanEventHandler 中接收)。 您是否有任何方法可以从应用 MCU 打印日志？

如果是、请至少打印与接收到的事件关联的"id"。

如果不是这样、您可以在 上述函数中设置断点并检查错误状态。

BR、

Kobi

您好、Kobi、

如果我正确地记得、这些引脚多路复用设置对于其他 CC32xx 器件也是有效的、而不仅仅是 CC3220。 不再具有访问文档的权限、但应在"有用链接"页面内部链接文档。 因此、提供的 JAN 引脚设置应该可用。

Kris -我有一些关于捕获 NWP 输出的注释、您可以在切换引脚多路复用时参考这些注释

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/954460/cc3220s-launchxl-possible-issue-in-simplelink-4-30-6/3527502#3527502

基本上、如果您可以在 UART 数据流中以921600波特率使用的备用引脚看到一些可识别的明文、则您将能够判断其是否正常工作。

此致、

Michael

谢谢、但我仍然无法验证(在文档中)这是否适用于 cc3200。

Michael 认为值得一试。

谢谢大家。 我将继续并尝试将记录器重新路由至另一个 UART。 我还将收集 NWP 版本并发布该版本。 请允许我在几天内完成该实验、并返回更多信息。

跟进问题。 如何对 NWP Service Pack 进行编程？ 它是否附带工厂的一个？

即使他们通过 Uniflash 加载的是在不同 NWP SP 上运行的相同 bin /相同设置、也有可能吗？这就是为什么只有部分器件存在此问题的原因？

您好、Kris、

服务包编程由 Uniflash 完成、由用户负责。 Service Pack 也可以通过 OTA 更新。 Uniflash 预计会对最新的 Service Pack 进行编程(为此、您需要更改 Uniflash 映像设置)。 如果在初始生产编程期间未完成此编程步骤、这肯定不是很好。

CC3200MOD 包含一些出厂时的 ServicePack 版本。 ServicePack 的版本因模块的制造日期而异、无法轻松预测。 如果在 Uniflash 生产期间未格式化 SPI 闪存、则该出厂 SP 将保留在此处。 但是、如果您格式化闪存而不是编程 ServicePack、则将在没有 Service Pack 的情况下使用器件。 作为第一步、您需要确定生产编程的外观(如果有的话、应该对什么 ServicePack 进行编程)。

1月

谢谢 Jan！ 通过与他们的讨论、我相信他们只对器件的 MCU 侧进行编程、因此 SP 很可能是出厂时提供的任何内容。 我将创建一个程序来记录故障和未故障器件的不同 NWP 版本、然后让它们在之后进行升级。

您好！

是的、这听起来是一个很好的计划。 您的问题可能与旧服务包或缺失服务包有关。

1月

SlVersionFulll 中的哪些实际参数表示服务包？ 在他们从我收到的批次中的一个器件上、NWP 版本为2.2.0.1。 但是 、我可以找到的最新 Service Pack 下载 版本为1.0.1.15-2.14.0.0。

我遇到了一个看起来与 sl_DevGet 有关的奇怪问题。 该函数看起来会返回、因为它能够在之后流式输出 NWP 信息、但它始终会触发看门狗复位、有时会在数据流的中间触发看门狗复位。 我已经尝试在呼叫前后处理看门狗。 似乎是因为它导致某种东西在某处挂起、所以我无法确定2.2.0.1是否可靠。

您好！

由于 WiFi 协处理器包含来自此原因的多个内核(NWP、MAC、PHY)、因此 ServicePack 编号包含多个数字。 2.2.0.1版是由一些非常旧的 Service Pack (比如7年前)提供的 NWP 版本。 NWP 版本是识别特定 ServicePack 的好方法。 在您的案例中、ServicePack 极旧、这可能会导致许多互操作性问题。

使用 sl_DevGE() API 时没有理由发出(通过 WDT 冻结/重新启动)。 这个问题听起来像是您的代码中的一些实现问题。

BTW... 您是否在异步处理程序中使用 SL_ API？ 因为 CC3200器件禁止这种情况。

1月

您好、Jan、

感谢您提供相关信息。 下面是我拥有的器件的完整列表：

芯片67108880
MAC 31.1.2.0.2
PHY 1.0.3.23
NWP 2.2.0.1
ROM 13107
主机1.0.0.10

我已经解决了看门狗复位问题。 在代码的该部分中使用时、sprintf 会过度运行栈、这似乎是一个问题。 我重定位了它、不再重置。 调试的问题真的很奇怪、但不想再花时间调试它！

我将在下周向客户发布此版本、以便开始收集有关故障器件的数据。 我不会进行任何 NWP 日志记录、直到我们看到新服务包中的问题是否仍然存在。

您好！

是的、这听起来很好。 我认为更新 ServicePack 可以很好地解决您的问题。

从主机驱动程序版本来看、您的代码似乎基于非常旧的 SDK 1.10 (2015年2月)。 更新 SDK 版本可能也是合理的。

1月

早上好。 我今天是坏消息的持有者。 客户端应用了服务包和 SDK 更新、但仍遇到故障。

升级前：

芯片67108880

MAC 31.1.2.0.2

PHY 1.0.3.23

NWP 2.2.0.1

ROM 13107

主机1.0.0.10

升级后：

芯片67108880

MAC 31.1.6.0.2

PHY 1.0.3.37

NWP 2.14.0.0

ROM 13107

主机1.0.0.10

他们通过 SSID 扫描仪记录中断、该扫描仪显示中断。 此处显示了问题单元(突出显示为蓝色)。 有趣的是、服务包似乎使广播强度变得更好一些、但最终仍然导致中断、迫使他们重新启动设备。

这是使用 TI Launchpad 还是在定制电路板上实现的？ 如果是定制板、他们可以在 LaunchPad 上复制吗？

您是否有关于导致此问题的系统状况的更多信息？ (是否仅在通道6中发生？ 只有 Eero 网状网络在附近？)

它位于定制板上。 我之前曾建议过 TI LaunchPad 创意、因为我相信它将清楚地表明它是器件问题还是设计问题。 奇怪的是、器件的 MCU 部分在 NWP 下降(看起来基于我们拥有的数据)时保持正常工作。 我将再次提出这个问题、但我不确定它在现场的环境中有多实用。

这似乎只发生在特定的场址。 该位置确实有 Eero 网状路由器、他们正在与该位置讨论切换到另一个接入点的问题、以查看其他数据点的问题是否已解决(请注意、CC3200也配置为 AP、因此未连接到 Eero)。 到目前为止、问题似乎仅发生在通道6上。 他们在通道11上有一个事件日志、但该设备与记录器远程、因此可能只是信号强度问题。 该设备不需要重新启动即可再次检测到 SSID。

它们在特定位置有相当多的器件-大约10个。 他们只有少数人会有问题。 我要求他们提取上面发布的所有信息、以确保其匹配。 除此之外、如果我们后退一步缩小范围、我们可以做些什么来进一步隔离这个问题？ 我可以请求他们将故障器件位置与同一现场位置的正常工作器件交换、然后查看其是否与器件一致。 LaunchPad 是个好主意。  还有其他想法吗？

接下来、我将了解我们是否可以通过引脚分配重映射实现 NWP 日志记录、但需要一些时间才能实现。

在 NWP 上执行 sl_stop()和 sl_start()会产生什么影响？ 这是真正执行处理器复位还是仅复位状态机？

这确实会复位处理器。