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.

CC3220SF: CC3220SF update functionality is broken after update is interrupted in certain position

Part Number: CC3220SF

We are using TI OTA_Lib to implement firmware updates on device with CC3220SF (MODASF to be precise).  As we want in some cases to use updates from SD card rather then download form web, we are bypassing part of OTA_Lib interface and using OTA_Archive directly.

Our app does following:

1. OTA_init is called

2. We are using exporting value of OtaLib_t *pOtaLib from OtaLib.c

3. Chunk by chunk data from update.tar on SD card is sent to OtaArchive_process using (&pOtaLib->OtaArchive) as first argument.

4. After reboot and OTA_init  OTA_get with EXTLIB_OTA_GET_OPT_IS_PENDING_COMMIT used to check whether there is pending commit or not and after that rollback or commit new image.

Usually it works good, but if update is interrupted (we are simulating power loss) during unpacking of root or intermediate certificate, all consequent update attempts will fail: OtaArchive_process will return ARCHIVE_STATUS_ERROR_CLOSE_FILE and following log will be printed to log:

OtaArchive_RunParseTar: error on pCloseFile, Status=-10288
OtaArchive_Rollback: ERROR sl_FsCtl, Status=-10282

Devices that lock up in the field because of power loss is not something we want. Maybe there is some way to recover device after such failure or way to prevent this? 

  • Hi Vadym,

    Which certificates are you trying to update as part of your TAR bundle?

    Best regards,

    Sarah

  • Hello Sarah,

    These certificates are part of certificate chain used for signing firmware image binary. Here is picture from swpu332, I marked certificates I am talking about with yellow arrows.

  • Hi Vadym,

    Can you create the certificates with the fail-safe flag?

    Best regards,

    Sarah

  • Hi Sarah

    What exactly do you mean ?

    From what I see those certificates are already failsafe, but on next load (after interrupted update) certificate which was not closed before reboot is marked as "No valid copy". They are not rolled back because they are not part of the bundle.

    By the way I reflashed my device and simulated interrupted update once more, now I get slightly different errors in logs, but device still won't update:

    OtaArchive_RunParseTar: error on pCloseFile, Status=-10288
    OtaArchive_Rollback: Successfull rollback

  • Hi Vadym,

    It sounds like your issue is that the certificate is corrupted when you remove power during the update. Error -10288 means the file has not been closed correctly. "No valid copy" occurs if the file was created without a failsafe flag.

    Can you share how you are configuring the certificate? Are you adding this in the application or the ImageCreator tool?

    Best regards,

    Sarah

  • Hi Sarah

    We are using following commands to invoke imageCreator and add certificates:

    "./$IMAGE_CREATOR_BIN" project add_file --name "$IMAGE_NAME" --file "$DIST_CERT_ROOT" --fs_path "$DIST_CERT_ROOT_NAME" --overwrite --max_size $DIST_CERT_ROOT_MAXSIZE

    "./$IMAGE_CREATOR_BIN" project add_file --name "$IMAGE_NAME" --file "$DIST_CERT_INTERMED" --fs_path "$DIST_CERT_INTERMED_NAME" --overwrite --max_size $DIST_CERT_INTERMED_MAXSIZE

    path to imageCreator binary is substitiuted as IMAGE_CREATOR_BIN

    DIST_CERT_ROOT_NAME and DIST_CERT_INTERMED_NAME are names for those certificate files under which they will appear in simplelink FS

    Should we add --flags failsafe option to these lines?
  • Hi Vadym,

    Yes, exactly. This flag will instruct the filesystem to keep a backup copy of those certificates, so if you remove power while those files are open, there is still a valid copy.

    Best regards,

    Sarah