OTA orchestrator PAL interface

OTA orchestrator demo shows how to download file from iot core and calls the OTA as completed without performing any pal related operations. The signature verification of downloaded image and self-test is what marks the image complete. Console logs from the demo show a message that “OTA completed successfully” but the job does not move to completed state because the device does not go to self-test mode and mark that new image was accepted.

I understand PAL is specific to a device and there will be different interfaces for different devices but the demo should provide an interface for PAL that can be used for performing PAL related operations.

Example link: freertos-core/over-the-air-updates/mqtt-ota-agent-orchestrator

Hello @pmamz!

I was able to try out the OTA Agent Orchestrator demo and confirm that it does indeed mark the job as completed. Below are my logs from the demo and a screenshot of the AWS Console showing the job.

For context, the self-test state while nice to have isn’t necessary for the cloud job to show as completed. The only thing that is needed is that the device sends back the job completed message. This is done in these lines of the demo.

Logs:

[WARN] pthread_attr_setstack failed with return value: 22. Default stack will be used.
[WARN] Increase the stack size to PTHREAD_STACK_MIN.
[WARN] pthread_attr_setstack failed with return value: 22. Default stack will be used.
[WARN] Increase the stack size to PTHREAD_STACK_MIN.
[WARN] pthread_attr_setstack failed with return value: 22. Default stack will be used.
[WARN] Increase the stack size to PTHREAD_STACK_MIN.
[WARN] pthread_attr_setstack failed with return value: 22. Default stack will be used.
[WARN] Increase the stack size to PTHREAD_STACK_MIN.
[WARN] pthread_attr_setstack failed with return value: 22. Default stack will be used.
[WARN] Increase the stack size to PTHREAD_STACK_MIN.
Suspend resume task 
D Transport_OpenSSL: Successfully imported root CA.
D Transport_OpenSSL: Successfully imported client certificate.
D Transport_OpenSSL: Successfully imported client certificate private key.
D Transport_OpenSSL: Setting server name <redacted>.iot.us-east-1.amazonaws.com for SNI.
D Transport_OpenSSL: Established a TLS connection.
Successfully connected to IoT Core
OTA Event Queue created.
OTA Event Sent.
OTA Event received 
Received Event is 1 
Request Job Document event Received 
-------------------------------------
OTA Event Sent.
OTA Event received 
Received Event is 2 
Received Job Document event Received 
-------------------------------------
Received OTA Job. 
OTA Event Sent.
OTA Event received 
Received Event is 4 
Request File Block event Received 
-----------------------------------
Starting The Download. 
OTA Event Sent.
OTA Event received 
Received Event is 5 
Received File Block event Received 
---------------------------------------
Downloaded block 0 of 1. 
OTA Event Sent.
OTA Event received 
Received Event is 6 
Close file event Received 
-----------------------
Downloaded Data Hello World!
 
OTA Completed successfully!
Unrecognized incoming MQTT message received on topic: $aws/things/ota_orchestrator_thing/jobs/AFR_OTA-OTA_Orchestrator_Demo_Test_1/update/accepted
Message: {"timestamp":1715019364}
Unhandled incoming PUBLISH received on topic, message: $aws/things/ota_orchestrator_thing/jobs/AFR_OTA-OTA_Orchestrator_Demo_Test_1/update/accepted
{"timestamp":1715019364}

And this is what the console shows me…

If possible, can you share your logs of the demo?

Also - keep in mind that if you select the ‘continuous’ job type then the job will not show as complete at the top level but will show the device as having completed the job. See this doc page for the full explanation.

It was an error on my side because I commented out the status update message. The execution does go into Success state as we send the “Succeeded” message.

I have another question about the job update status message. Older OTA had a configurable parameter that allowed to send the update after “x” number of publish for data blocks. This is removed in the modular OTA and status update is sent only towards the end when all the blocks has been removed. Is there any plan to add that support or is it upto the user to update the blocks if the user wants to see correct blocks in job execution?

We are happy to have the contribution of the update after X blocks functionality. At the moment we do not have someone working on that.

1 Like