• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 1105 视图
  • 用户 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.

[参考译文] LAUNCHXL-CC3235SF：有关 OTA 的问题。

admin
Guru**** 2543180 points
Other Parts Discussed in Thread: CC3200, CC3235SF, UNIFLASH

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1172748/launchxl-cc3235sf-questions-about-ota

器件型号：LAUNCHXL-CC3235SF
主题中讨论的其他器件：CC3200、 CC3235SF、 UNIFLASH

大家好、

以下是客户的请求：

客户希望对 OTA 使用内部更新方法、但 他不知道如何将.tar 文件写入 SimpleLink 文件系统。

在之前的 CC3200项目中，bin 文件的原始数据通过 TCP 接收，然后通过 sl_ FsWrite()写入文件系统。 而不 是更改 mcubootinfo 并重新引导 MCU、从而轻松完成 OTA。

 他们现在可以使用 CC3235SF 实现这一点吗？ 是否也可以通过这种方法将.tar 文件写入文件系统、是否有任何相关的方案？

您可以帮助检查此案例吗？ 谢谢。

此致、                                                        

Nick

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

    您好、Nick、

    是的、您的客户可以通过文件系统 API 将.TAR 文件写入 sFlash、然后处理该.TAR 文件。 但更好的方法是动态处理.TAR 文件。 该主题可能有用。

    1月

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

    TAR 文件使用 Uniflash 或 CCS 创建(请参阅创建 OTA 选项、例如 在 https://www.ti.com/lit/swru469中)。

    它允许更新一个捆绑包中的多个文件(即 MCU 映像、服务包和/或用户文件)- TAR 被提取到一个文件系统中、其中包括  https://www.ti.com/lit/pdf/swra510中描述的具有元数据的不同文件。

    云和本地 OTA 方法支持动态解析 TAR 文件(即在从云加载 TAR 文件期间或从移动设备接收到 TAR 文件时) 这样，TAR 中的每个文件在收到后就会作为一个单独的文件存储在文件系统中。 如果 TAR 仅包含一个文件、则云 OTA 方法  将等同于 MCU 映像或服务包的 CC3200更新(使用 HTTP GET 请求从云服务器检索内容)、但 OTA 库(通过 Uniflash/CCS 创建 TAR 文件) 启用对整个捆绑包完整性的另一级别验证(通过 Uniflash/CCS 对整个 TAR 文件内容进行签名并通过器件验证签名)以及捆绑包保护(即确保整个捆绑包正常、否则所有内容都将恢复到最后工作内容)。

    在"内部更新"方法中、想法是整个 TAR 文件已存储在文件系统中、并且 TAR 的解析(即在 OTA 映像中保存单个文件)是离线完成的。 用户/应用程序负责在内部更新开始之前将 TAR 文件存储在文件系统中。

       

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

    您好、Kobi、

    以下是进一步请求：

    1.  使用 local_Ota 例程时、 会在 upload_file 时报告错误。  串行端口打印：握手过程中发生[sock error]可恢复错误- 346 (sl_error_bSD_ESEC_certificate_unknown)。  原因是什么？  。 在 example_tar 中选择的 tar、自生成的也会报告此错误、最终导致 OTA 失败。
    2. 在 simplelink_cc32xx_sdk_6_10_00_05中、为什么  在 MQTT_CLIENT 中放置示例 local_OTA 更复杂？  他是否继续通过引用您提供的动态分析方法进行设计、或使用 MQTT_客户端示例？

    此致、                                                        

    Nick

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

    您好、Nick、

    我们这个问题的专家 Kobi 本周已经离开。 他将在下周初回来。

    感谢您的耐心等待。

    Jonathan  

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

    您好、Nick、

    我不确定-346。 客户端证书链中的内容似乎已损坏(验证文件的名称和证书使用者的常用名称是否匹配)。 确保整个链(根 CA 除外)位于文件系统上。 如果无法识别问题、请提供空气嗅探 器(Wireshark)日志或 NWP 日志(请参阅 https://www.ti.com/lit/swru455中的第20章)。

    关于 SDK 6.10中的 local_ota -您能解释一下更复杂的内容吗？ 它应该更简单(应用程序只需调用 OTA_IF_uploadImage()即可 开始等待 来自对等设备的连接，应用程序无需执行任何其他操作，并且只会在收到文件时收到通知)。 您提到的分析方法是什么？

    BR、

    Kobi