• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 268 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3220MODA: How to begin to use an OTA downloaded certification file?

Hideaki Nambu
Mastermind 9165 points
Part Number: CC3220MODA


(The part number is CC3220MODA.)

Hello,

Please assume a single cert file has been downloaded. Now an exinsting one is in use.
Then how to replace it to the newer one?
Is it up to user, like using file system API like remove the older and remane the newer files to the "Issued by" filename, and add error handlings..?


In the fact I'm reading swru455e.pdf, 7.10 - File Commit Feature.
It would be useful for me, but it was not clear for me if the file replaces when the new file is commited.

  • 0
    TI__Mastermind 40965 points
    Hi,

    If you have a new certificate, or any other single file in general that you wish to overwrite in a safe manner, you can use the failsafe option to ensure that allow you to temporarily overwrite the old file with your new cert. If a file is created with the failsafe flag, then when you open a file for write you are actually writing to a secondary file that will contain your new data tentatively. Only once you commit that file is the original removed and the secondary file marked as the new, permanent data. The original data will not be kept on the filesystem once the new data is committed.

    Of course, this is just an optional feature. If your original certificate file was not marked as a failsafe file during initial programming, then you can use the sl_FsOpen()/sl_FsWrite() APIs to directly overwrite a file without any backup. A good resource for understanding the filesystem APIs is the Secure Filesystem SimpleLink Academy module:

    dev.ti.com/.../

    If you are trying to update this file alone and not through the provided OTA library, then you will need to handle errors and perform your own testing of the new file first. If you are updating this file through the OTA library and providing it as part of a bundle of files, then it will handle the low-level file writes and all you need to do is a functional test once the OTA writes the new data before committing.
    Let me know if you need more clarification or if you have further questions on this topic.

    Regards,
    Michael
  • 0 in reply to Michael Reymond
    Mastermind 9165 points

    Michael,
    Thank you for your response.
    Your link shows the commit feature. I would like to suggest it to my customer.
    Before that please let me confirm:

    Q. The commit operation for a single file, is it failsafe or not?
    For example, swru455g.pdf, chap-(8.9.3 Commit a Bundle) & -(8.9.4 Rollback a Bundle), says that the commit/rollback operation for the "Bundle" is fail-safe:
    >>
    The commit process is fail-safe; that is, if the device has been shut down during the bundle commit procedure, on power-up the device automatically continues the bundle commit process.
    <<

    But the same sentence was not found in the chap-(8.10 File Commit Feature).
    I concern a power-loss during the file state operation. After that the file state value in the flash memory has marginally charged bits and the value reads both "standard file" and "SL_FS_INFO_PENDING_COMMIT" according to the environment.

  • 0 in reply to Hideaki Nambu
    TI__Mastermind 40965 points
    Hi,

    For the bundle feature, the guarantee is that either all of the files in the bundle are committed, or all of the files are not committed in case there is some reset or other glitch during the commit process.

    For an individual file, if there is a power loss during when it has the new data but not committed, it will revert back to the original data. If this power loss occurs during the commit process itself for the one file, then either it can be reverted back to the original data or it could be committed to the new data permanently, depending on where in the commit command the reset occurs. As there is only one file to worry about there is no need for a guarantee as you cannot result in a bad state from this reset. The failsafe process ensures that you cannot end up with the old data but also with pending commit flag somehow, so you can try updating the file again in that case.

    Regards,
    Michael