My implementation consists of an altered version of wireless_uart baremetal example (available in SDK_2.2_QN908XCDK). It sends 100000 bytes to another device by consecutively writing 410 packets of 244 bytes in the wireless_uart characteristic value in the connected device (as if someone would write 100000 bytes over wireless UART application using NXP Tool Box).
I'm using the same App_PostCallBackMessage(BleApp_FlushUartStream, NULL) to create an event and add the msg for the app_thread to process when the main_task is eventually executed. The BleApp_FlushUartStream uses GattClient_WriteCharacteristicValue API to write the value in the connected device Gatt Server.
The Client Procedure Callback is triggered when writing is complete, and another event is set to write the next packet using the same procedure described for the first packet.
Although, after about 230 packets written, the GattClient_WriteCharacteristicValue API starts to return gBleOverflow_c. Based on this forum discussion https://community.nxp.com/thread/500240, the BLE adds the commands to an internal queue that eventually gets full and the applications are required to wait.
I tried to wait random periods (some seconds) before trying to resume the process. However, it was noticed that after some time that the API returns gBleOverflow_c, the whole BLE stack halts and it stops responding to reading and writing command, even disconnects and does not respond to connection tries. In this situation, is it required to restart the application for it to work correctly.
How can I avoid this situation where this internal queue gets full?
Is there another more appropriate method for transferring a large amount of data using BLE? Our goal is to transfer up to 8 MB of sensor data in one connection.
