[参考译文] CC3220SF：NWP 偶尔崩溃

您好！

NWP 记录器之前已共享过很多次。

您只需插入->影像/视频/文件。

什洛米

e2e.ti.com/.../NWP_5F00_Logs.zip

您好！

这是日志文件。 我想就所出现的问题提供更多详细信息。 HTTP 请求在一段时间内正确发送、这样 NWP 不会将请求转发给处于空闲任务中的 MCU。 之后,所有请求都由 NWP 应答,而不是由 HTTP 服务器应答。

您好！

日志不可解码。 您过去是否获取过日志？

那么芯片 CC3220还是 CC3200、您用这两种方法都可以？

什洛米

大家好、Shlomi、为我的同事添加 Im 标记

我们过去从未获取过记录、
我们当前正在使用 CC3220SF Launch XL 对其进行测试、其中 UART2_0通过接头引脚55和57连接到外部板。 假设需要切换到 UART2_1的外部连接以通过 UART2_0启用 NWP 日志记录、我是否正确？ 我们有必要连接外部电路板来演示问题所在。
如果是、我还要假设我们需要使用 uart2驱动程序将 UART2_0配置为文档中给出的设置(波特：921600、8N1)？ 或者只需添加以下行就足够了吗：

//如果您的应用程序已经配置了 UART0，则不需要此行
MAP_PRCMPeripheralClkEnable (PRCM_UARTA0、PRCM_RUN_MODE_CLK)；
//将多路复用器引脚62连接到模式1，以输出 NWP 日志
MAP_PinTypeUART (PIN_62、PIN_MODE_1)

按照文档中的说明进行初始化、

尊敬的 Shlomi：

 我已附上更新后的日志文件供您查看。 请您确认它们现在是否可解码？

e2e.ti.com/.../5621.NWP_5F00_Logs.zip

是的、这些是可解码的、但看起来很正常。 我想它不包括这个问题、对吧？

你好 Shlomi, Ilija 告诉我,问题应该出现在这些日志。 我们发送了请求、直到我们在 CC3220SF MCU 上无法再收到它们为止、但我们一直收到404响应。 我们将再次记录日志、以防万一、他将很快发布这些日志

项目便是基于 此。 调试中、一旦错误发生、MCU 仍然完全正常运行。
您能想到的还有什么其他东西会阻止我们在 MCU 上接收 http 请求？ 一旦此问题出现、我们就会发现 MQ_RECEIVE 函数绝不会触发、而我们继续直接从 NWP 获得404响应。

您好 Shlomi、这里是新日志 files.e2e.ti.com/.../7360.NWP_5F00_Logs.zip

谢谢、我周末回来的时候、会在周日查看。

您好！

我没有看到主机应卡住的任何具体原因。

我可以在你得到404错误时看到它一次。

如果存在名为"www/err_404.html"的文件(在本例中为真)、cc3220会将其作为 HTML 404 Not Found 页面发送给客户端。

也许这就是你看到的。

但我无法看到主机停止响应。

什洛米

您好 Shlomi：

404响应不应该出现。 相同的请求通常会在它发生之前预先发送给 MCU、在它发生之后、请求永远不会再次到达 MCU、我们不断从 NWP 获得404自动响应。
如前所述、在查看 MCU 代码的 ROV 之前、一切似乎都正常工作、sl_Task 和 HTTP 服务器任务在正常位置被阻止、就像在等待一个请求到达、但从未如此。 这就好像 NWP 被卡住了、针对每个到达的请求自动发送404响应。
我们不知道为什么这是第一次发生,因为相同的请求在这之前正常运行,但在看似随机数次后,这种错误将发生。
我们不知道为什么在它第一次发生后,我们再也不会收到 MCU 上的请求和404响应自动发送
对于如何进一步调查此问题、您有什么建议吗？

如果这造成任何差异、我们目前使用的是5.20版本的 SDK、原因是存在兼容性和认证转移问题

您好！

至少从日志中可以看出、NETAPP_request 来自 NWP、并且相应的 NETAPP_RESPONSE 从主机以挂起标志触发回 NWP、这与在其他良好情况下相同。 我假设其他命令(不是 HTTP)也可以从主机正常运行、对吧？

因此、我们需要了解在挂起标志发出信号后为什么看不到任何 NETAPP_SEND。 它在您的代码中的什么位置触发 NETAPP_SEND？

什洛米

因此、cc3220sf MCU 上的请求只能在一个地方通过 HTTP 服务器任务内的 mq_receive 接收、此部件未从之前提供几个响应的示例中进行修改。 在之前关于 Kobe 的其他问题的经验中、我已经确定 sl_Task 负责接收 NWP 的请求并解除阻止从队列读取请求的 HTTP 服务器任务。

我们使用 sl_NetappSend 将响应发送、有两种方式之一。 解析后从 http 请求的回调函数调用它、或者将请求保存在 http 请求回调中、并且在接收到来自外部板的 UART 响应后在 UART 回调中调用 sl_NetappSend。

我们会看到在错误发生后、MQ_Receive 或 sl_NetappSend 未在调试中触发。 在错误发生之前、我们可以看到它们正常触发

sl_Task()负责获取 NETAPP_request 并使用带挂起标志的 NETAPP_RESPONSE 进行回复。 您可以在 sl_opcode_netapp_request 条件下的_SlNetAppEventHandler ()中看到它。 它还 通过 _SlDrvDispatchNetAppRequestEvents ()调用匹配的应用程序处理程序。 此处理程序通常会调用 netapp_send。 如果您正在使用消息队列从处理程序传递到另一个任务、则应检查是否到达处理程序、如果是、则消息队列可能已崩溃/已满/其他。