Other Parts Discussed in Thread: UNIFLASH,
Hi. I have written a custom serial port method of accepting firmware upgrades, which for a while worked just fine. However, suddenly it halts with an error when trying to verify the ota.sign and the ota.cmd against the certificate. Currently trying to use the "dummy_ota_vendor_cert.der". When I recompile OtaArchive.c with
#define OTA_FORCE_SIGNATURE_VERIFICATION (FALSE)
and create the tar ball without signature in Uniflash, it installs the new firmware just fine. However, with this set to TRUE, verifySignature() fails because
Status = sl_NetUtilCmd(SL_NETUTIL_CRYPTO_CMD_VERIFY_MSG, (uint8_t *)&verAttrib,
sizeof(SlNetUtilCryptoCmdVerifyAttrib_t), verifyBuf, SHA256_DIGEST_SIZE + SigFileSize,
(uint8_t *)&verifyResult , &resultLen);
... returns -10369, aka SL_ERROR_FS_FILE_IS_ALREADY_OPENED, just like it says in the thread title.
Has anyone seen anything similar, or know what this could be? On the face of it, calling sl_NetUtilCmd on a buffer in RAM (which is the ota.cmd and the ota.sign concatenated) and getting an error that a file is already in use really doesn't make sense.
sl_NetUtilCmd(SL_NETUTIL_CRYPTO_CMD_INSTALL_OP... succeeds, which it doesn't if I give the certificate the wrong name. So the part that seems to open a file works, but the part that is supposed to use that file to verify the signature returns a file-opening related error message.
Some background: I took out just the OtaJson and the OtaArchive from the regular ota system, and transfer bytes in packets using a proprietary, already existing protocol. Whenever I have more than 512 bytes in the receive buffer, I call OtaArchive_process, just like normal. The reason for this is that my product is in transceiver mode, listening for some specific L2 packets, forwarding them to a server over the other protocol and never associating with an AP.
