gBleOverflow when using QN9080 SDK write to attribute API.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

gBleOverflow when using QN9080 SDK write to attribute API.

1,223 Views
renatozapatalus
Contributor I

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.

Labels (1)
0 Kudos
4 Replies

1,026 Views
kishans
Contributor III

Hello Estephania,

   Am also facing the exact similar issue as explained above by renatozapatalus,  the only one difference in my side is we are using GattDb_WriteAttribute write the response data to notifier. And we already configure gAppMaxConnections_c to 1.  Try to resend the packet after getting gBleOverflow erro, but it never seems to improve any of the above mentioned situation. kindly let me know if there is a way to get rid off this issue @estephania_mart 

 

0 Kudos

1,062 Views
estephania_mart
NXP TechSupport
NXP TechSupport

Hello,

Let me check it and investigate further on this.

Regards,
Estephania

0 Kudos

1,062 Views
estephania_mart
NXP TechSupport
NXP TechSupport

Hello,

Could you please try decreasing the number of gAppMaxConnections_c to 2 ? The example has it by default in 16.

Regards,
Estephania

0 Kudos

580 Views
shubhs156
Contributor I

Hi I'm facing the same issue after 2 years, I have set the max connections to 1, but that didn't help.

Did anyone find a solution?

Tags (1)
0 Kudos