[参考译文] CC3220S：OtaArchive.c、sl_NetUtilCmd (sl_NETUTIL_crypto_CMD_verify_MSG、... 返回-10369、也称为 SL_ERROR_FS_FILE_IS 已打开

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1132956/cc3220s-otaarchive-c-sl_netutilcmd-sl_netutil_crypto_cmd_verify_msg-returns--10369-aka-sl_error_fs_file_is_already_opened

你(们)好 我已经编写了一个接受固件升级的自定义串行端口方法、这种方法已经使用了一段时间了。 但是、在尝试根据证书验证 OTA.SIGN 和 OTA.cmd 时、它突然停止、并出现错误。 正在尝试使用 "dummy_ota_vendor_cert.der"。 将 OtaArchive.c 重新编译时

#define OTA_FORCE_signature_verification          (错误)  

并在 Uniflash 中创建没有签名的 tar 包、即可安装新固件。 但是，如果将此设置为 true， 则 verifySignature()会失败，因为

状态= sl_NetUtilCmd (sl_NETUTIL_crype_CMD_verify_MSG、(uint8_t *)&verAttrib、
sizeof (slNetUtilCryptoCmdVerifyAttrib_t)、verifyBuf、SHA256_Digize_size + SigFileSize、
(uint8_t *)&verifyResult，&resultLen)；

(笑声) 返回-10369、也称为 sl_error_fs_file_in_already 已打开、就像线程标题中所说的那样。

是否有人看到过类似的东西、或知道这可能是什么？ 表面上、在 RAM 中的缓冲区(即 OTA.cmd 和 OTA.SIGN 连接)上调用 sl_NetUtilCmd、并得到一个文件已在使用的错误实际上毫无意义。

SL_NetUtilCmd (SL_NETUTIL_crypto_CMD_INSTALL_OP)... 成功、如果我为证书指定了错误的名称、则不会成功。 因此、似乎打开文件的部分正常工作、但应该使用该文件来验证签名的部分返回与文件打开相关的错误消息。

一些背景信息：我从常规 OTA 系统中取出了 OtaJson 和 OtaArchive、并使用专有且已经存在的协议传输数据包中的字节。 只要接收缓冲区中的字节超过512个、就像平常一样调用 OtaArchive_Process。 原因是我的产品处于收发器模式、侦听某些特定的 L2数据包、通过 其他协议将它们转发到服务器 、并且从不与 AP 关联。