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的问题

Part Number: LAUNCHXL-CC3235SF
Other Parts Discussed in Thread: CC3235SF, CC3200, UNIFLASH

我想使用Internal Update方式进行OTA,但是不知道如何将.tar文件写入到SimpleLink文件系统,以前的CC3200项目是通过tcp接收bin文件原始数据通过sl_FsWrite()写入文件系统,更改mcubootinfo重启MCU,这样很方便就完成了OTA,现在使用CC3235SF也能这样操作吗,也可以将.tar文件通过此方法写入文件系统吗,可以给出相关的方案吗?

  • 您好,

    感谢您的对TI产品的关注!为更加有效地解决您的问题,我需要多一些时间查看这个问题,稍后会为您解答。

  • 您好,

    是的,您可以通过文件系统 API 将.tar 文件写入 sFlash然后处理该.tar 文件。但更好是使用on-the-fly(动态解析)的方法处理.tar 文件。您可以参考该帖:链接

    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 文件内容进行签名并通过器件验证签名)以及捆绑包保护(即确保整个捆绑包正常,否则所有内容都将恢复到最后一个工作内容)。

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

  • 1.我在使用local_ota例程,在upload_file的时候报错,串口打印:[SOCK ERROR] Recoverable error occurred during the handshake -346(SL_ERROR_BSD_ESEC_CERTIFICATE_UNKNOWN),这是什么原因,.tar选择的example_tar里面的,自己生成的也要报这个错,最后导致OTA失败。

    2.simplelink_cc32xx_sdk_6_10_00_05把local_ota例程放在了mqtt_client里面为什么更复杂了,我是继续参考你给的动态解析方法进行设计,还是用mqtt_client例程。

  • 您好,

    由于节假日的关系,工程师会延迟回复,感谢您的理解。有答复立即联系您。

  • 我现在准备使用ota_archive.h/c files进行动态解析,.tar文件通过Tcp_socket接收,不使用HTTP服务器,参考了你给的链接,好像不能先将.tar文件通过文件系统写入 sFlash,因为.tar文件太大了,我想知道:.tar文件可以通过Tcp_socket接收然后调用OtaArchive_Process() 处理吗,OtaArchive_Process() 这个函数会将有用信息写入sFlash吗,可以告诉我大概的流程是怎样的?

  • 您好,

    收到您的跟进消息,帮您同步工程师。有答复立刻回复您。

  • 您好,

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

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