TI中文支持网Part Number:LAUNCHXL-CC3235SFOther Parts Discussed in Thread:CC3235SF, CC3200, UNIFLASH
我想使用Internal Update方式进行OTA，但是不知道如何将.tar文件写入到SimpleLink文件系统，以前的CC3200项目是通过tcp接收bin文件原始数据通过sl_FsWrite（）写入文件系统，更改mcubootinfo重启MCU，这样很方便就完成了OTA，现在使用CC3235SF也能这样操作吗，也可以将.tar文件通过此方法写入文件系统吗，可以给出相关的方案吗？
Nick Sun：
您好，
感谢您的对TI产品的关注！为更加有效地解决您的问题，我需要多一些时间查看这个问题，稍后会为您解答。
,
Nick Sun：
您好，
是的，您可以通过文件系统 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 文件存储在文件系统中。
,
HS：
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例程。
,
Nick Sun：
您好，
由于节假日的关系，工程师会延迟回复，感谢您的理解。有答复立即联系您。
,
HS：
我现在准备使用ota_archive.h/c files进行动态解析，.tar文件通过Tcp_socket接收，不使用HTTP服务器，参考了你给的链接，好像不能先将.tar文件通过文件系统写入 sFlash，因为.tar文件太大了，我想知道：.tar文件可以通过Tcp_socket接收然后调用OtaArchive_Process() 处理吗，OtaArchive_Process() 这个函数会将有用信息写入sFlash吗，可以告诉我大概的流程是怎样的？
,
Nick Sun：
您好，
收到您的跟进消息，帮您同步工程师。有答复立刻回复您。
,
Nick Sun：
您好，
我们不确定-346的原因具体是什么。客户端证书链中的内容（验证文件的名称和证书使用者的常用名称是否匹配）似乎是已损坏。要确保整个链(根 CA 除外)位于文件系统上。如果无法识别问题、请提供无线嗅探器（类似Wireshark）的日志或 NWP 日志（请参阅 https://www.ti.com/lit/swru455 中的第20章）。
关于 SDK 6.10中的 local_ota -您能解释一下哪些地方是更复杂了吗？它应该是更简单了（应用程序只需调用 OTA_IF_uploadImage()即可开始等待来自对等设备的连接，应用程序无需执行任何其他操作，并且只会在收到文件时收到通知）。您提到的分析方法是什么？
