• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 687 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.

CCS/CC3220SF: Using OTA Library for General File Download

Michael Fuhrmann
Intellectual 770 points
Part Number: CC3220SF
Other Parts Discussed in Thread: UNIFLASH

Tool/software: Code Composer Studio

We want to use the OTA library to download a firmware on a 2538 chip that is connected to the 3220sf. We are successful at downloading the tar using the library in mode OTA_FILE_DOWNLOAD. Once OTA_run() returns OTA_RUN_STATUS_DOWNLOAD_DONE all seems like we wish. However the OTA library is in a wrong state. If we try downloading a new package  OTA_run() returns OTA_RUN_STATUS_DOWNLOAD_DONE straight away with downloading.

- Was the OTA designed to handle simple file downloads generated with Uniflash?

- What would be the way to use it this way?

The OTA library does a lot ( downloading , parsing the package, checking signings ) it would be as shame if it could only be used for the host binary running images.

  • 0
    TI__Guru 63006 points

    Hi,

    As you mentioned the OTA library (specifically ota_archive.c) does more then just loading the tar file (over HTTP). It parses the received tar content on the fly and handles the included files (i.e. stores them in the file system and verify their digests and the overall image signature). When download is complete the library handles the MCU reset which will enable the new update (with fail-safe protection).

    The OTA_FILE_DOWNLOAD flag means that library will skip the cloud server specific negotiation (checking if a new update is available and then getting the url for loading the file). So the assumption is that you are not using GITHUB or DROPBOX, but using your own server and providing the direct link to the OTA file.

    For just reading a file you don't need the OTA library and can use the HTTPClient library.

    You can refer to the HTTPGet example that demonstrates the use of the HTTPClient library. 

    Note that the OTA library uses a different version of an HTTP Client (part of the lib) which is triggered from the OtaLib state machine, through calls to  CdnClient_ConnectFileServer, CdnClient_ReqFileContent, CdnClient_RecvSkipHdr and CdnClient_RecvAppend. You can uses this but the recommended way is through the standard HTTPClient as demonstrated in the HTTPGet example.

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Intellectual 770 points

    Thanks for your response. We cannot use HTTPGet, we are downloading the binaries for the coordinator and other zigbee sensors. In my mind OTA simply has a be able to download, process and check other OTA binaries. So I’ve made some changes to the OTA library to be able to use it for for that purpose. In OTA_set I’ve added a case:

    case EXTLIB_OTA_SET_OPT_RESET:

           pOtaLib->ConsecutiveOtaErrors = 0;

           _OtaCleanToIdle(pOtaLib);

           CdnClient_Init(&pOtaLib->CdnClient, pOtaLib->NetBuf);

           OtaArchive_init(&pOtaLib->OtaArchive);

           break;

    Which I call upon case OTA_RUN_STATUS_DOWNLOAD_DONE only after having downloaded a .tar without a .bin. This seemed to work at first. I can repeatedly download files, however when I push a cc3220 .tar with a .bin this fails :

    int16_t verifySignature(char *pSig, uint32_t SigFileSize, uint8_t *pDigest)

    If I push a .tar with a .bin FIRST all is OK, but as soon as I perform a file download, subsequent cc3220 binary fail the signature. So there must be something that isn’t reset properly. Here are two screenshots, one with a fail and one with success. I can see pDigest is different and verifyBuf is different. It’s exactly the same .tar that is downloaded. I’m very close to getting it working, so any input very welcome.

  • 0 in reply to Michael Fuhrmann
    TI__Guru 63006 points

    It is still not clear what you are trying to do.

    When saying ".bin", are you referring to "sys/mcuflashimg.bin"? (or to 2538 image?)

    Are you calling sl_Stop when the download completes? The internal state of the NWP is updated when you download a new MCU image. 

    I'm not sure how this is related to the signature calculation/verification.

    What do you mean by "FIRST all is OK"? did you completed a full ota cycle? 

    Please share more details regarding your use-case. What exactly are you trying to get from the library?

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Intellectual 770 points

    Thanks Kobi.

    There are two scenarios:

    1) I download a sys/mcuflashimg.bin for the 3220. That logic starts and ends exactly how the OTA is intended to. It downloads, checks, mcu reboot, happy days.

    2) I download a tar that does NOT contain a sys/mcuflashimg.bin. for the sake of simplifying things lets forget about the 2538. Let's say the TAR contains an image with name blablabla.png.

    The changes I made in the OTA only apply to case 2. When the download is done the changes in the OTA code are meant to reset the OTA process because when the download is done I'm happy, I have my blablabla.png. Resetting enables the OTA library to perform another case 1 or 2 after the download is done of a case 2 without being stuck in an unfinished state.

    I can perform case 2 multiple times.

    I cannot perform case 1 after case 2 has been performed. The screen shots I've included in the previous post is the error when I perform case 1 after having performed case 2.

    In a nutshell, the changes I've made to the OTA library are to enable the download and check of a .tar WITHOUT a sys/mcuflashimg.bin.

    I hope I cleared things up.

  • 0 in reply to Michael Fuhrmann
    TI__Guru 63006 points

    When doing 1 - did you commit the changes after the MCU reset?

    If I understand correctly, you are trying to avoid the MCU reset in case 2. Did you try keeping the reset in this case?

  • 0 in reply to Kobi Leibovitch
    Intellectual 770 points

    Hi Kobi.

    In Case 1 I do a OTA_set(EXTLIB_OTA_SET_OPT_IMAGE_COMMIT after the reboot. Effectively in case 1 I stick precisely to the original OTA library logic and it works fine.

    I did not try keeping the reset in case 2. I know I could simply do a reset to completely reset the OTA library and not having the issues that I'm experiencing, but that's really not how this should work.

    I just need to find the right memory to reset in the OTA library.

    I think the person(s) who originally wrote the library would get to the point in no time. Anyway you can forward? 

  • 0 in reply to Michael Fuhrmann
    TI__Guru 63006 points

    Hi,

    The OtaArchive_init() should reset all the relevant parameters.

    The only exception i can think of is the internalBufLen (in  _BundleCmdFile_Parse). Make sure it is being zeroed.

    It is supposed to get reset but if it is not you can make it global and reset it within OtaArchive.

    Br,

    Kobi