OTA session fail after several successful file block transfers

Partners & Sponsors AWS
1

Am working at EK-RA6M3 evaluation board from Renesas and using the DA16000 WiFi module.

Was able to get the demo from Renasas working with ethernet. But am encountering issue when using the WiFi module instead.

Am observing that after a suspended message and resumed message, the file block received will be reset back to 0.
The suspended OTA message is usually received around the 13th file block.

logs:
[INFO] In Function: prvRunOTADemo(), Received: 14 Queued: 14 Processed: 13 Dropped: 1
[INFO] In Function: prvMqttJobCallback(), Received OTA job message, size: 1999.
[INFO] In Function: prvMQTTSubscribe(), Subscribed to topic $aws/things/ra6m3_ota_demo_thing/streams/AFR_OTA-xxxxxxx/data/cbor.
[INFO] In Function: prvRunOTADemo(), Received: 0 Queued: 0 Processed: 0 Dropped: 0

Checking AWS log, got the disconnect reason as “MQTT_KEEP_ALIVE_TIMEOUT”.

Would appreciate any insights and help for this observation.

2

As documented here:

MQTT_KEEP_ALIVE_TIMEOUT happens when there is no client-server communication for 1.5x of the client’s keep-alive time; the client is disconnected.

Whats the keep-alive time for MQTT configured on the device? You can check the value assigned to the keepAliveSeconds of the MQTTConnectInfo_t data type used in the MQTT_Connect API.

Try increasing the value and check if that improves the tests.

3

Hi Tony,

Have tried increasing the keepAliveSeconds and the duration it takes for the demo to hit the suspend message increased.

However, the issue still persist. After resuming the OTA, the file blocks starts back at 0.

image
image829×406 6.59 KB

4

Im guessing while you receive file blocks, your MQTT agent task is not getting enough CPU time to send the MQTT PINGEQ before the timeout.

I would try creating a timer (SW) or a higher-priority task that will periodically call the MQTTAgent_Ping before the keep alive time expires, so that I can conclude that in fact the case.