pvyawaha
commented
2 years ago Hello @laszlopataki ,
The otaconfigOTA_UPDATE_STATUS_FREQUENCY is available as OTA library configuration option and you can configure it as per your requirement for how frequently the status update is required. The current implementation is to consider device is receiving the file after otaconfigOTA_UPDATE_STATUS_FREQUENCY number of blocks are received. However it will be useful to update the status just after receiving the first block and I will take it as a small feature request. I will update here when this is added.
ActoryOu
Describe the bug When you start a new OTA Job for a device the
otaconfigOTA_UPDATE_STATUS_FREQUENCYtells how frequently the device should report a status. The condition below resusts that the 1st packet will not report status.if( ( received % otaconfigOTA_UPDATE_STATUS_FREQUENCY ) == 0U )This causes the misunderstanding of "why the OTA did not start" and desynchronization between the actual status of the OTA and what AWS IoT Core tells us. The problem is magnified if the IoT device has a narrow bandwidth and the packet transfer is slow. In this case, you can see Queued status for minutes while the OTA is actually running. If the binary is transferable in a smaller number of packets than otaconfigOTA_UPDATE_STATUS_FREQUENCY, then the status will never change to "In Progress". Same situation if the OTA "Timed Out".
Subtitute 1 from
otaconfigOTA_UPDATE_STATUS_FREQUENCY, or extending the condition withreceived == 1can solve the issue.System information
Expected behavior The OTA Agent sends a status update to IoT Core at the first packet and after at every
otaconfigOTA_UPDATE_STATUS_FREQUENCY.