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.

CC3220S-LAUNCHXL: Fix for OTA Always Being Stuck on Same Version

Part Number: CC3220S-LAUNCHXL

There was a bug in the OTA library, addressed by the following post: 

However, a bug remains. As written the FSM for the OTA library will not properly progress to other archives, even though the comparison is correct. The fix is to do the following:

1. In OtaLib.c, comment out the line, below:

 case OTA_STATE_CHECK_ARCHIVE_NEW_UPDATE:
        {

            uint8_t *pVersionFileName;
            _SlOtaLibTrace(("OTA_run: CdnClient_GetNextDirFile\r\n"));
            pOtaLib->pOtaFileName = CdnClient_GetNextDirFile(pCdnClient, &pOtaLib->OtaFileSize);

            /* check if last file in the list, still without tar file */
            if( pOtaLib->pOtaFileName == NULL)
            {
                /* tar file not found, return no updates */
                _SlOtaLibTrace(("OTA_run: ERROR CdnClient_ReqOtaDir - tar not found, no updates\r\n"));
                pOtaLib->ConsecutiveOtaErrors = 0;
                pOtaLib->State = OTA_STATE_IDLE;
                _OtaCleanToIdle(pOtaLib);
                return OTA_RUN_STATUS_NO_UPDATES;
            }

            _SlOtaLibTrace(("OTA_run: CdnClient_GetNextDirFile: file=%s, size=%ld\r\n", pOtaLib->pOtaFileName, pOtaLib->OtaFileSize));

            if (strstr((const char *)pOtaLib->pOtaFileName, ".tar") == NULL) 
            {
                _SlOtaLibTrace(("OTA_run: WARNING, not a tar file, filename=%s\r\n", pOtaLib->pOtaFileName));
                /* Stay on state, check next file version */
                pOtaLib->State = OTA_STATE_CHECK_ARCHIVE_NEW_UPDATE;
                return OTA_RUN_STATUS_CONTINUE;
            }

            /* continue anyway, user app can override this decision */

            // COMMENT THIS LINE OUT

            //pOtaLib->State = OTA_STATE_REQ_FILE_URL; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


            /* Init the Tar parser module */
            OtaArchive_init(&pOtaLib->OtaArchive);

2. Add in OTA_set:

case EXTLIB_OTA_SET_OPT_ACCEPT_UPDATE:
            /* check if after OTA_STATE_CHECK_ARCHIVE_NEW_UPDATE state */
            if (pOtaLib->State != OTA_STATE_CHECK_ARCHIVE_NEW_UPDATE)
            {
                _SlOtaLibTrace(("OTA_set: ERROR EXTLIB_OTA_SET_OPT_ACCEPT_UPDATE in wrong state = %d\r\n", pOtaLib->State));
                return OTA_OPT_ERROR_WRONG_STATE;
            }

            pOtaLib->State = OTA_STATE_REQ_FILE_URL;
            break;

3. If you wish to DECLINE an update, don't call Ota_set, just do nothing.

These changes will enable the FSM to progress. 

Happy to send a patch if there is a mechanism to do that. 

  • Hi,

    I understand your code, but I'm not sure I understand what was the original issue.

    Was there a real bug or you prefer a different method (without calling OTA_set when the OTA_run returns OTA_RUN_STATUS_CHECK_OLDER_VERSION)?

    Br,

    Kobi

  • Hi Kobi,

    As best as I can tell, I believe there is bug in the current implementation.


    1) Assume a directory with 3 firmware versions:

    • 0.tar
    • 1.tar
    • 2.tar

    2) Assume the current system version number is 0.


    The way the FSM is implemented, if the first element in the list of firmwares downloaded is either 1.tar or 2.tar, an update will proceed.

    However, if the first file retrieved is 0.tar, the FSM will do the following:

    1) In state OTA_STATE_CHECK_ARCHIVE_NEW_UPDATE it calls:

    /* continue anyway, user app can override this decision */
    pOtaLib->State = OTA_STATE_REQ_FILE_URL;

    2) A return value from OTA_Run of OTA_RUN_STATUS_CHECK_OLDER_VERSION will be returned. A user can decline this update, however, this prevents the FSM from iterating over the remaining archives.

    3) The result is that the newer update files are not seen, if there exists a version equal to the current version and it is the first version in the downloaded list.

  • That's correct. I understand the issue.

    Why would you leave the old tar file in the directory?

    I think this issue was not raised before, because typically you would remove the obsolete tar file.

    Anyway, I would report this and we would fix it in one of the next releases.

    Thanks,

    Kobi

  • Hi Kobi, 

    Sure thing, where can I report it?

    As to why leave the old files, I think it's a matter of a) it wasn't obvious to me that was the behavior and b) I was considering situations wherein updates might have to be applied in sequence to be valid. Perhaps not always needed but I didn't want to be boxed in.

    FWIW I ended up using the model where a file is directly downloaded from a URL. I have my app ping the server with its current version number and ask which version it should download, if any. I was experiencing a lot of intermittent failures with the dropbox integration. The direct download seems more stable in my testing.  

    Thanks!

  • You've just reported... (this is the forum to report issues, we will take it from here).

    br,

    Kobi