• 状态
  • 已锁定 已锁定
  • 回复 14 回复
  • 订户 0 订户
  • 视图 661 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

admin
Guru**** 2482105 points
Other Parts Discussed in Thread: CC3200, CC3220SF

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1330082/cc3220sf-nwp-crashes-sporadically

器件型号：CC3220SF
主题中讨论的其他器件：CC3200、

您好！

我遇到了网络处理器的问题、这给了我一些麻烦、我希望从该领域的 TI 专家那里获得一些指导或见解。

当从 CC3200器件成功发送一系列 HTTP 请求时、就会出现问题。

经过该序列后、网络处理器没有响应。 我注意到、发生这种情况时 CC3200仍停留在空闲任务中、器件需要重新启动才能恢复功能。

为了解决此问题、我生成了 NWP 日志文件、我认为这些文件可以提供有关问题根源的宝贵见解。

但是、我不知道如何发送这些日志文件、因为它不允许我将其上载到此处。

非常感谢您的指导和帮助。 您可以提供的任何建议、建议或见解对于解决此问题非常有帮助。

提前感谢您投入宝贵的时间给予大力支持。

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

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

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

    什洛米

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

    您好！

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

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

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

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

    什洛米

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    大家好、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)

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

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Shlomi：

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

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

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

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


  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

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

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

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

    也许这就是你看到的。

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

    什洛米

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Shlomi：

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

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

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

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

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

    什洛米

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

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

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

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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