[参考译文] CC3235MODAS：未连接到 Wi-Fi 路由器。

从 NWP 收到异步错误事件时、您是否有任何指示？

复位器件后会发生什么情况？

代码是否包含配置？ (在配置示例中、如果器件在2秒内未连接到存储的配置文件之一、则会进入配置。

假设您支持 AP 配置-您可以检查器件是否处于 AP 模式。   

您能否获得 NWP 日志(请参阅 https://www.ti.com/lit/swru455中的第20.1章)。

从 NWP 收到异步错误事件时、您是否有任何指示？

->不、因为器件没有可用的 UART 或 JTAG 接口。

复位器件后会发生什么情况？

-->重置意味着重新启动 MCU。 我们正在执行休眠重新启动。 连接到路由器之后。

代码是否包含配置？ (在配置示例中、如果器件在2秒内未连接到存储的配置文件之一、则会进入配置。

->是的、我们最初会将开始阶段的 CC3235用作 AP 模式。 在我们进行自定义配置后、我们将其模式更改为工作站模式。 我们已检查、如果没有可用的 Wi-Fi 配置文件、则它将再次进入 AP 模式。

当 CC3235未连接到路由器时、我们还检查了 CC3235是否未处于 AP 模式。 这就是为什么我们在重新启动时、CC3235将直接尝试与路由器连接而不进行访问的原因。

您可以获取 NWP 日志吗？

否

我们有一个问题、如果 CC3235是 Wi-Fi 路由器连接模式的自动连接模式、那么它为什么会停止发送信标。 如果我们重新启动 MCU、则其工作正常。 到目前为止，我们还找不到任何完美的方案。 因为它在行为上完全是随机的。

我们猜路由器的连接可能太多、所以路由器拒绝了 CC3235在这种情况下的请求、CC3235处于某种理想状态、不再尝试连接。 不确定我们是否正确。  

此致

Pulkit Prajapati

您好 Kobi Leibovitch、

感谢你的帮助。

您能否获得802.11空气监听器(例如 Wireshark)捕获？

-->是的，我将向您发送个人信息。 请接受我的请求。

器件仅在 AP 模式下发送信标、可能会因为移动到基站模式而停止。

-->是的，正确，但如果它处于站点模式，我们注意到它正在发送探测请求，该请求是在监听器中捕获的。

我们注意到、有一个设备连接到路由器、但它不会发送任何回调日志、例如"STA Connected to the AP：xyzw"。

在这种情况下、我们有"sl_DeviceGet (sl_device_General、&configOpt、&configLen、(_u8 *)(&DateTime)"时间请求、其响应为-2017 (SLNETERR_RET_CODE_STOP_IN_PROGRESS)。

那么、在这种情况下该怎么办呢？

总结-两种问题。

其中一个器件将连接、但它卡在"mqTTClient_connect (gMqttClient)"内。 Time Get 请求中的"sl_DeviceGet (sl_DEVICE_General、&configOpt、&configLen、(_u8 *)(&DateTime)"-2017 (SLNETERR_RET_CODE_STOP_IN_PROGRESS)上的错误。 (这是第一次捕获)

2.其中设备不会连接任何路由器，也不会发送在监听器中捕获的任何数据包。 (大多数情况下发生)

我对此有几个问题。

1.如果我们在器件卡住后捕获 NWP 日志、对您有何帮助？ 因为我们不知道哪个器件会出现此问题。

2.异步事件是什么意思？ 处理程序"SimpleLinkSockEventHandler"及其案例 SL_Socket_ASYNC_EVENT。 对吗？

附加点。

我们已经添加了堆内存和堆栈溢出挂钩。 但它不会到达那里。

此外、我们还为测试器件安排了 UART 日志。 但一旦器件卡住、就不会出现日志。

实际上、我们在实验室中实际有15个器件处于运行状态以测试此场景、并且在客户现场有将近30个器件。 因此、解决方案的需求是一个非常紧迫的基础、因为它会使我们的生产周期受阻。

此外、我们还尝试为您捕获 NWP 日志。 请等待、这种情况需要在其中一个器件中再次发生。

此致

Pulkit Prajapati

您使用的是什么服务包？

如果可能，请更新到最新版本(4.11.0.0)

我批准了连接。 请将相关设备和路由器(MAC)地址信息添加到监听器日志中。

是的、我们使用的是最新版本。(sp_4.11.0.0_3.7.0.1_3.1.0.26)

好的。 我将检查日志、并在找到任何内容时进行更新、