This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Fixing Azure FOTA Error update job (id 32) was already attemped, aborting

I've been working on firmware updating devices from Microsoft Azure, and when pushing new firmware update to devices (NRF9160), some of the devices has failed downloading the firmware.

But the problem is, that when trying to re-download the firmware (etc. rebooting) the device the log writes the following error message:

<wrn> azure_fota.azure_fota_msg_process: Update job (ID: 32) was already attempted, aborting

And then it won't try to download the firmware. 

I've tracked the log down to line 686 in azure_fota.c where the following check is:

if (!is_new_job()) {

        LOG_WRN("Update job (ID: %s) was already attempted, aborting",
            log_strdup(reported_job_id));
        rep_status_set(REP_STATUS_CURRENT);

        return 0;
}
 
I've "fixed" it with the following hack:
    if (!is_new_job() && (evt.version == fota_object.version)) {
        LOG_WRN("Update job (ID: %s) was already attempted, aborting",
            log_strdup(reported_job_id));
        rep_status_set(REP_STATUS_CURRENT);

        return 0;
    }
My question is: Is there any major risk I take with this implementation, and what is the main reason, why it won't ever try to re-download a the firmware?
SDK version 1.5.0
Parents
  • Hello, and sorry for the delayed answer. 

    The fix you have introduced could, according to our developers, end in an endless loop. The best solution is to update with a new ID for the failing devices. 

    Kind regards,
    Øyvind

Reply
  • Hello, and sorry for the delayed answer. 

    The fix you have introduced could, according to our developers, end in an endless loop. The best solution is to update with a new ID for the failing devices. 

    Kind regards,
    Øyvind

Children
  • the solution was working fine, and we have succesfully updating many hundred devices the last last month without any errors or failed devices, but last week we encountered four devices, that wouldn't download, they were "out in the field" so I couldn't attach debug concole, and they lost connection afterwards and weren't able to retain. I remembered your answer and thought they maybe were related to this. Is it possible to for you to elaborate a bit on how they can end in an endless loop. And is it possible to update the job id from the failed device, or should that be from Azure? As I'm not interested in updating the job ID manually.

    The use case is that we want failed devices to just keep trying to re-download the firmware until succesfull.

    Best regards.

  • Hello Tobias, 

    My sincere apologies for not providing an answer to your last comment. I did forward your question to our developers after receiving the PM from you, but have not heard back. I will poke them again to provide an answer. 

    Kind regards,
    Øyvind

  • The closest to an explanation is the following:

    If we retry the same firmware download again and again, we could end up in an endless loop of downloading, for instance if they have an error in the image that makes the bootloader reject it. That would be expensive for the customer...
    The Azure FOTA implementation (which is not an official Azure offering, it's just a tutorial from them that we've expanded a bit on) is not as sophisticated as for instance AWS jobs
Related