I’m working on OTA over cellular and I’m running into a problem. Even though I chose my OTA file block size 1024 bytes, I get replies from the AWS IoT core which are longer than 1460 bytes, which is the buffer size of my cellular modem.
For instance, after this log item:
[INFO] [OTADemo] [OtaOverMqttDemoExample.c:1510] Sent PUBLISH packet to broker $aws/things/SIM7080G_Development/streams/AFR_OTA-b2d067cd-7422-4e6f-9569-9c1b2b3273e1/get/cbor to broker.
the received reply is longer than 1460, causing the cellular receive buffer to overflow.
It here a way to limit the reply length? What would be the best way to approach this issue?
The OTA library configuration for block size is the actual size of the data blocks in which the OTA file is split and excludes all the other overhead. You can configure the file block size of 512 ( minimum is 256 ) to leave some room for overhead.
The buffer overflow already occurs before block transfer is started, so choosing a smaller block size does not help. After this publish call from the OTA agent
[INFO] [OTADemo] [OtaOverMqttDemoExample.c:1510] Sent PUBLISH packet to broker $aws/things/SIM7080G_Development/streams/AFR_OTA-b2d067cd-7422-4e6f-9569-9c1b2b3273e1/get/cbor
a long reply is received from IoT core which is longer than the maximum buffer size of my modem hardware. That reply is independent from the file block size.
Attached is a log that runs from initial boot all the way until the problem occurs.
The log is a combination of:
-AWS library logs
-AT commands sent and received
-Logs from my own custom library which is the link in between a transport layer socket and the modem AT commands.
During the log an OTA job is started and the last publish call generates a long reply from IoT core, too long to fit into my modem buffer.
I’m really close to getting OTA to work with my own cellular driver. If I cannot solve this, I will have to switch to a modem supported by the FreeRTOS Cellular Core Interface instead, but I’d rather not. I have already invested quite a lot in my current modem.
Thank you for sharing the logs. I do not see why buffer should overflow based on the response received ( less than the buffer available ). Are you still facing the issue or you were able to resolve this?
Ik kept running into issues with this modem and was not happy with the technical support from the manufacturer. So in the end, I decided to switch to a different modem for my design. I switched to uBlox and got that to work.