How to know if firmware update job has been scheduled or not before creating/initializing OTA Agent?

Dear All,

I am using the OTA Agent library of FreeRTOS and I am successfully able to download, verify and flash the new firmware to my MCU.

But most of the times I do not have the firmware update job created in the AWS IoT core because I do not have any new firmware that needs to be upgraded in the MCU but still the OTA agent task (named as “prvOTAAgentTask” in aws_iot_ota_agent.c) is still waiting in the infinite loop for any new firmware update because I created the OTA Task by calling “OTA_AgentInit()”.

Actually the behavior which I want to implement is that if there is no firmware update job created in the AWS IoT core, then I should turn off my network interface device which in my case is cellular modem. Is there any API or SDK function available in FreeRTOS which can give me information if there is any firmware update job created in the AWS IoT core or not. Accordingly I will call the “OTA_AgentInit()” to create the OTA task if there is any firmware update job scheduled. Else I will not call “OTA_AgentInit()” because there is no need for it and turn off my cellular modem to save power.

Please help me on how to solve this requirement of mine.

Thanks and Regards,
Sritam Paltasingh.

Hello ,

Can you please share which version of the library you are using ?

The OTA Agent when idle is subscribed to the job notifications topic and waits for new job notification. If the requirement is to turn off the network interface then job notifications can not be received by the device. This requires some polling from the application on device and the polling frequency will depend on the application and power requirements. For example OTA Agent can be started once every 24 hours from the application and allowed to run to process any jobs in queue and shutdown using OTA_AgentShutdown API. You can check the status of the Agent using OTA_GetAgentState , if it is waiting for a job for some period then OTA Agent can be shutdown and restarted at next polling interval.

Please let me know if you have further questions.

1 Like

Hi Pvyawaha,

Thanks for your valuable information. Your suggested approach is one of the good ways to turn off the modem when FOTA is not available. We actually turn off the modem while our device is on charging so as to quicken the charging process.

But I found out another approach by which it can be known whether any OTA job is scheduled or not. The approach is as follows:
When we start the OTA process by calling the public API “OTA_AgentInit()”, the OTA Agent task is created internally by the library with a priority of 2.
Then the OTA Agent task uses its internal logic and finally calls the private function “prvPAL_Abort()” which FreeRTOS OTA Library expects us to define it. The private PAL functions are interfaces between our application and the FreeRTOS OTA library. The prvPAL_Abort() function declaration is something like this:
OTA_Err_t prvPAL_Abort(OTA_FileContext_t* const fileContext);

The “fileContext” function parameter of the function can be used to know if any OTA job was scheduled or not. If (fileContext->ulFileSize == 0), then it means that no OTA job is scheduled in our AWS cloud because of which the file size is zero.

In case there is any FOTA job scheduled in the AWS cloud then the download starts and the created OTA Agent task calls the private function prvPAL_Abort() at the end of the download. But in this case the “fileContext->ulFileSize != 0” and the size is equal to the size of the image file which was scheduled in our AWS cloud and which got downloaded by the OTA Agent task.

In this way we determined that if FOTA is scheduled or not without creating any timer as suggested by your approach. Then we immediately turn OFF the modem and let the charging complete in lesser time. This approach of us seemed simpler and we went ahead to implement this and it works fine.

Thanks and Regards,
Sritam Paltasingh.

Thank you for sharing this information. We have added the OTA_FileContext_t to all the OTA PAL APIs for such custom implementations. Please let me know if you have any more questions.