[参考译文] CC3220SF-LAUNCHXL：使用 HTTP 时无法将器件连接到移动应用。

请提供更多详细信息、因为您使用的是我们不直接支持的 Amazon FreeRTOS 代码。

我不确定他们使用的配置机制是什么。

您所指的状态机在哪里？

如果我理解正确： 连接到 CC3220的移动设备(在配置软 AP 模式下(在从本地网络断开连接后)并获取 IP 地址。  然后在 HTTP 连接期间失败。  您可以确认吗？

您好、Kobi、

 
感谢您的回答。  

 
我正试图以明确的方式重写下面的问题陈述。

我正在使用外部确认、 根据影子文档的声明状态、云连接正在建立。

 执行以下步骤来重现问题(仍然是随机问题)

1.获取影子文档

2.影子成功

3. 遗憾的是 ，设备与 AP 断开连接，(设备与 AP 断开连接时出现错误！！ )

4.配置已停止。

5.由于配置失败，无法 连接到 AP (无法连接到 AP 或配置文件不存在)

6.再次开始配置 (器件被称为 AP 角色)。

  
问题是、在步骤6中、设备正在托管、并且也能够在 Wi-Fi 列表中将设备视为 AP。 但对于移动应用程序(尝试建立 HTTP 连接)、设备根本没有响应。  

配置过程与 TI 示例代码相同。  

请查找随附的 Provisioning.c 文件。
 e2e.ti.com/.../provisioning.c  

  
请查找调试日志以供您参考。

SET TO FIXED FREQUENCY.
Simple Link task created
Device came up in Station mode
[OCR_RecordAndClear] ManufacturingTestEnabledflag : 0 , ProvisioningCommandedRestartflag : 0.
Device came up in Station mode
[Provisioning task] Provisioninig task initialized
[Provisioning task] Device started as STATION
[Provisioning task] validateLocalLinkConnection() sem wait
[Provisioning task] validateLocalLinkConnection() sem exit ret=0, status=0
[Provisioning task] Cannot connect to AP or profile does not exist
[Provisioning task] detected device is CC3220SF
[NETAPP EVENT] IP Acquired: IP=10.123.45.1 , Gateway=10.123.45.1
[Provisioning task] Device is configured in default state
[Provisioning task] Current: 0, Event: 0, Next: 1
[Provisioning task] Device started in AP role
[NETAPP EVENT] IP Acquired: IP=10.123.45.1 , Gateway=10.123.45.1
[Provisioning task] Host Driver Version: 2.0.1.27
[Provisioning task] Build Version 3.14.0.0.31.2.0.0.0.2.2.0.7
[Provisioning task] Starting Provisioning -
[Provisioning task] in mode 2 (0 = AP, 1 = SC, 2 = AP+SC)
[Provisioning task] Provisioning Started. Waiting to be provisioned..!!
[Provisioning task] Current: 1, Event: 1, Next: 2
[WLAN EVENT] Profile Added
[WLAN EVENT] Connection to AP succeeded
[WLAN EVENT] IP address acquired
MQTT library successfully initialized.
Shadow library successfully initialized.
Establishing new MQTT connection.
Shadow GET of was ACCEPTED.
adiSmsGetShadowInfo(): acquired shadow document:
Shadow UPDATE was ACCEPTED.
sent new state report.
Disconnecting connection.
Connection disconnected.
Network connection closed.
Network connection destroyed.




Device disconnected from the AP on an ERROR..!!



Device disconnected from the AP on an ERROR..!!



Device disconnected from the AP on an ERROR..!!




[Provisioning task] Current: 2, Event: 3, Next: 3
[WLAN EVENT] Provisioning stopped
[WLAN EVENT] - WLAN Connection Status:1
[Provisioning task] Cannot connect to AP or profile does not exist
[Provisioning task] Current: 0, Event: 6, Next: 0
[NETAPP EVENT] IP Acquired: IP=10.123.45.1 , Gateway=10.123.45.1
[Provisioning task] Device is configured in default state
[Provisioning task] Current: 0, Event: 0, Next: 1
[Provisioning task] Device started in AP role
[NETAPP EVENT] IP Acquired: IP=10.123.45.1 , Gateway=10.123.45.1
[Provisioning task] Host Driver Version: 2.0.1.27
[Provisioning task] Build Version 3.14.0.0.31.2.0.0.0.2.2.0.7
[Provisioning task] Starting Provisioning -
[Provisioning task] in mode 2 (0 = AP, 1 = SC, 2 = AP+SC)
[Provisioning task] Provisioning Started. Waiting to be provisioned..!!
[Provisioning task] Current: 1, Event: 1, Next: 2



-->>>>>>>>> HERE HTTP is not working, but able to see the device name <<<<<<<<------

部分打印件与代码不匹配：

在状态2 (WAIT_Foir_IP)中接收到的事件3 (断开连接)应导致状态1 (等待连接)而不是3。

事件6是 PROVISIONING_SUCCESS -与打印稿无关。

是导致与 AP 断开连接、还是只是发生了这种情况？ 什么是原因代码(可在 SimplelinkWlanEventHandler 中找到)？

抱歉、附加了正确的文件(请注意、这是一个代码片段、可能缺少一些定义)

e2e.ti.com/.../new_5F00_provisioning.c

作为固件测试的一部分、与 AP 的断开是手动完成的。

谢谢

我不确定 具体发生了什么、但它似乎与应用相关。

在配置过程中(配置设置后)、移动设备应离开 AP (我猜 "器件因错误而与 AP 断开连接！！" 相关-我在您的代码中找不到此内容)。  

我还看到收到了事件确认成功("[配置任务]当前：2、事件：3、下一步：3")

然后、下一个事件(6 = WaitForConn ->该事件的触发器是什么？)不是状态3 (PrvnState_Completed) 在状态0 (？)中接收

您好、Kobi、

问题的答案

然后、下一个事件(6 = WaitForConn ->该事件的触发器是什么？)不是状态3 (PrvnState_Completed) 在状态0 (？)中接收

在硬件上调试时观察到以下事件序列。

在此过程中，在步骤3中，将收到 PrvnEvent_ConfirmationSuccessess，并将 Provisioning stop 命令发送到网络处理器。 当我们从网络处理器获取配置停止事件(请参阅日志[WLAN Event]配置停止)时、如果 WLAN 状态未连接、则会发送 PrvnEvent_WaitForConn 事件。 因此调用函数 WaitForConn ()。 在此函数中、再次初始化配置(请参阅 new_provisioning.c 中的第641行和642行)。

为了确保网络处理器不会造成问题、我在 new_provisioning.c 中的第641行之前重新启动了网络处理器 但这并没有解决。

我根据您的输入检查了应用程序代码、但这个问题似乎与应用程序无关。

请指导我如何第二次初始化 HTTP 服务器、或者该问题的可能解决方案是什么。

对于我来说、很难对您所做的所有更改遵循代码-因此我将坚持询问有关 NWP 预期行为和事件的问题。

配置成功完成后-如何确保状态未连接？ 这毫无意义-如果配置成功、器件应该已连接。 (是否关闭路由器？)

我认为您只是在等待另一个连接事件、以下配置是冗余的、可能会导致问题。  

您是否正在验证 sl_WlanProvisioning 的返回代码？

您是否有更多信息(最好是监听器日志) 来更好地了解 HTTP 连接中的问题？

您可以尝试重置 NWP 或 HTTP 服务器：

//NWP RESET
sl_Stop(200); sl_Start(0,0,0);

// HTTP SERVER RESET
sl_NetAppStop(SL_NETAPP_HTTP_SERVER_ID); 
sl_NetAppStart(SL_NETAPP_HTTP_SERVER_ID)