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.

[参考译文] CC3220MOD:CC3220MOD 锁定状态

Guru**** 2540720 points
Other Parts Discussed in Thread: CC3220MOD, UNIFLASH

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1174888/cc3220mod-cc3220mod-lock-state

器件型号:CC3220MOD
主题中讨论的其他器件: UNIFLASH

大家好、

客户反馈说、在迁移到 SDK 6_10_00_05后、锁定问题再次出现。 请帮助您提出可能导致此问题的原因、谢谢。

此致、

水阳

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

    您好!

    请准确说明锁定问题的含义。

    此线程是否基于旧线程?

    谢谢、

    Shlomi

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

    您好、Shlomi、

    问题与旧线程完全相同。 有什么建议吗?

    BR、

    水阳

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

    您能给我指出上一个主题吗?

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

    您好、Shlomi、

    请按以下方式查找该帖子:

    https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1114485/cc3220mod-nwp-lock-happen

    此致、

    水阳

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

    因此、客户开始清理并升级了 SDK (以及 servicepack?) 它又发生了吗?

    正如 Jan 在前一帖子中建议的、由于第二个引导加载程序实现、可能会发生锁定状态。

    在锁定状态下、除了重新编程器件之外、无法恢复。

    大多数锁定状态都是由于文件系统的安全操作不良而导致的、我不确定您的操作是什么。

    Shlomi

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

    您好、Shlomi、

    客户升级了 SDK、但未升级服务包、他们使用的是出厂时随 CC3220MOD 一起提供的服务包。

    以下是从2个锁定模块和1个正常模块读取的 Uniflash:

    锁定模块 SDK_2_10_00_04:

    锁定模块 SDK_6_10_00_05:

    正常模块:

    更多背景信息:客户仅更新了应用程序代码、但未更新第二个引导加载程序。 第二个引导加载程序可以正常启动并加载应用程序、应用程序打印日志显示器件已锁定。

    BR、

    水阳

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

    您好!

    很难从描述中得知 NWP 为何被锁定。

    唯一的方法可能是连接 NWP 记录器并进行捕获、但如果应用程序卡住、我不确定是否可以执行。

    只需仔细检查、您就卡在 sl_Start() API 上、对吧?

    Shlomi

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

    您好、Shlomi、

    程序不会停留在 sl_Start()上,而是停留在 sl_WlanPolicySet()和 sl_DeviceGet ()上。

    SL_WlanPolicySet():[line:688、error code:-14343] WLAN error、please refer "WLAN errors codes" section in errors.h

    SL_DeviceGet ():[line:24、error code:-2011] Device error、please refer "device errors codes" section in errors.h

    BR、

    水阳

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

    谢谢、

    因此至少 sl_Start()起作用,以便您可以多路复用 NWP 记录器。

    您能否按照以下帖子中描述的步骤操作并检查您是否可以捕获日志?

    https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1050010/cc3220s-aws-iot-mqtt-connect-issue/3915033#3915033

    Shlomi

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

    您好、Shlomi、

    请查找附件中的日志:

    e2e.ti.com/.../CC3220S_5F00_Abnormal_5F00_ModuleA_5F00_logger.log

    e2e.ti.com/.../CC3220S_5F00_Abnormal_5F00_ModuleB_5F00_logger.log

    客户尝试使用 SL_FS_factory_RET_TO_image 和 SL_FS_factory_RET_TO_DEFAULT 来恢复锁定的模块、但应用程序文件已擦除(第二个引导加载程序仍然有效)。 这似乎与我们的文档不匹配:

    另一个问题是、是否有手动触发锁定状态的方法? 客户希望使用它来测试恢复方法是否正常工作。

    此致、

    水阳

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

    您好!

    您遇到的特定错误与其中一个文件的完整性不好有关。

    这是在读取操作文件(不是您的文件、而是系统正在使用的系统文件)期间完成的。

    这是获得该误差的唯一方法(最终会转换为应用层中的结果、即-14343)。

    由于完整性是在安全文件系统代码中计算的、因此无法重现确切的错误。

    我还可以看到、例如、servicepack 文件不在文件系统上。

    我们是否可以遵循步骤重现此场景?

    Shlomi

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

    您好、Shlomi、

    您能否指出哪个文件被破坏? 第二个引导加载程序是否会导致此文件损坏、或者只能由 NWP 访问?

    没有特殊的步骤可以重现错误、只是在正常操作期间发生。 但客户提到在运行期间器件可能会频繁复位(大约50年代)、这是否可以重新启动?

    客户只能在第二个引导加载程序中写入/读取文件/sys/myapp2.bin、而不能在应用程序中写入/读取。 以下是对第二个引导加载程序中的文件执行的操作、用于更新应用程序文件:

      ret = sl_Start(0,0,0);
      ret = sl_FsGetInfo(deviceFileName, 0,&pFsFileInfo);
      ret = sl_FsDel(deviceFileName,0);
    
      OpenFlags = SL_FS_CREATE | SL_FS_OVERWRITE | SL_FS_CREATE_MAX_SIZE( MAX_SIZE_128K );
      s_u32DeviceFileHandle =  sl_FsOpen((unsigned char *)deviceFileName, OpenFlags , (unsigned long *)&g_u32MasterToken);
     i32WriteCount = sl_FsWrite(s_u32DeviceFileHandle,s_u32WriteOffset, &pdata[7],u32DataLength);
      sl_FsClose(s_u32DeviceFileHandle, NULL, NULL, 0);
      sl_Stop(0);

    每次上电后的读数和读数:

       Status = sl_Start(0,0,0);
       iRetVal = sl_FsGetInfo(ImgName, g_u32MasterToken,&pFsFileInfo);
    
      lFileHandle = sl_FsOpen((unsigned char *)ImgName,SL_FS_READ,(_u32 *)&g_u32MasterToken);
      RetVal = sl_FsRead(lFileHandle,128, (unsigned char*)APP_IMG_SRAM_OFFSET,pFsFileInfo.Len-128);
      Status = sl_FsClose(lFileHandle, 0, 0, 0);
      
     Status = sl_Stop(0);

    请建议您在代码中是否存在任何风险、谢谢。

    此致、

    水阳

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

    您好!

    我所指的文件是存储 WLAN 配置文件的文件、但也可以是其他文件。

    这些文件是系统文件、因此应用程序不能直接访问这些文件、只需使用主机驱动程序 API 间接访问即可。

    无论如何、作为引导加载程序、我不确定您的操作是否准确、因此无法进行评论。

    我在您共享的代码片段中注意到、您使用的是 sl_Stop (0)、这意味着积极地关闭电源、并且它是在关闭文件后立即应用的、 这可能是一个问题、因为 NWP 需要一些时间来计算文件散列并将其存储到文件系统中。

    我建议通过向 sl_Stop()添加一个超时来正常停止器件、例如 sl_Stop (200)。 在这种情况下、NWP 具有200mSec 的处理能力、不仅可以正常处理您的案例中的文件系统、还可以处理其他网络任务。

    此致、

    Shlomi