• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 42 subscribers
  • Views 192 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LAUNCHXL-CC3235SF: Questions about OTA.

Nick Sun
Intellectual 2265 points
Part Number: LAUNCHXL-CC3235SF
Other Parts Discussed in Thread: CC3200, CC3235SF, UNIFLASH

Hi team,

Here's the request from the customer:

Customer wants to use the Internal Update method for OTA, but he don't know how to write the .tar file to the SimpleLink file system.

In the previous CC3200 project, the original data of the bin file was received through tcp, and then be written to the file system through sl_ FsWrite(). Than change mcubootinfo and reboot the MCU, which makes it easy to complete the OTA.

Can they do this with CC3235SF now? Can the .tar file also be written to the file system through this method, and is there any related scheme?

Could you help check this case? Thanks.

Best Regards,                                                       

Nick

  • +1
    Guru 73435 points

    Hi Nick,

    Yes, your customer can write .TAR file into sFlash by filesystem API and after that process this .TAR file. But better way will be process .TAR file on-the-fly. This thread can be useful.

    Jan

  • +1
    TI__Guru 61556 points

    The TAR file is created using Uniflash or CCS (see Create OTA option, e.g. in https://www.ti.com/lit/swru469).

    It enables updating multiple files in a bundle (i.e. MCU image, service pack and/or user files) - the TAR is extracted to a file system that includes the different files with metadata as described in https://www.ti.com/lit/pdf/swra510.

    The cloud and local OTA methods enable parsing the TAR files on the fly (i.e. during loading a TAR file from the cloud or while receiving it from a mobile device) - so that each of the files within the TAR is stored to the file system as a separated file as soon as it is received. if the TAR contains only one file then the Cloud OTA method will be the equivalent to a CC3200 update of an MCU image or service pack (retrieving content from a cloud server using HTTP Get request), but the OTA library (with TAR file creation by Uniflash/CCS) enables another level of verification of the entire bundle integrity (signing the entire TAR file content by Uniflash/CCS and verifying the signature by the device) as well as bundle protection (i.e. making sure the entire bundle is ok or everything will revert back to the last working content).

    In the Internal Update method, the idea is that the entire TAR file is already stored on the file system and the parsing of the TAR (i.e. saving the individual files within the OTA image) is done offline. It is user / application responsibility to store the TAR file in the file system before the Internal Update starts.

        

  • 0 in reply to Kobi Leibovitch
    TI__Intellectual 2265 points

    Hi Kobi,

    Here's further request:

    1.  When using local_ Ota routines, an error is reported when upload_file. Serial port printing: [SOCK ERROR] Recoverable error occurred during the handshake - 346 (SL_ERROR_BSD_ESEC_CERTIFICATE_UNKNOWN). What is the reason? . tar selected in example_ tar, the self generated ones also report this error, which eventually leads to OTA failure.
    2. In simplelink_cc32xx_sdk_6_10_00_05, why it is more complex when put example local_ota in mqtt_client? Does he continue to design by referring to the dynamic analysis method you give, or use mqtt_ Client example?

    Best Regards,                                                       

    Nick

  • 0 in reply to Nick Sun
    TI__Intellectual 1610 points

    Hello Nick,

    Our expert on the issue, Kobi, is out this week. He will get back to you early next week.

    Thank you for the patience.

    Jonathan 

  • 0 in reply to Jonathan Cohen
    TI__Guru 61556 points

    Hi Nick,

    I'm not sure about the -346. It seems that something is broken in the client certificate chain (verify the names of files and the certificate subject's common name are matching). make sure the entire chain (excluding the root CA) is on the file system. If you can't identify the problem please provide an air sniffer (wireshark) log or NWP log (see chapter 20 in https://www.ti.com/lit/swru455).

    Regarding local_ota in SDK 6.10 - can you explain what exactly is more complex? it should be simpler (the app just need to call OTA_IF_uploadImage() to start waiting for a connection from the peer device, the app doesn't need to do anything else and will just be notified when the file is received). What is the analysis method you refer to?

    Br,

    Kobi