<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic gBleOverflow when using QN9080 SDK write to attribute API. in Wireless MCU</title>
    <link>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/940814#M7388</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P style="margin: 0cm; margin-bottom: .0001pt; text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;My&amp;nbsp;implementation consists of an altered version of&amp;nbsp;&lt;STRONG&gt;wireless_uart baremetal&amp;nbsp;&lt;/STRONG&gt;example (available in&amp;nbsp;&lt;SPAN&gt;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&amp;nbsp;UART&amp;nbsp;application using NXP Tool Box).&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt; "&gt;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&amp;nbsp;&lt;SPAN&gt;GattClient_WriteCharacteristicValue API to write the value in the connected device Gatt Server.&amp;nbsp;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;Although, after about 230 packets written, the GattClient_WriteCharacteristicValue API starts to return gBleOverflow_c. Based on this forum discussion&amp;nbsp;&lt;A _jive_internal="true" href="https://community.nxp.com/thread/500240"&gt;&lt;SPAN style="color: windowtext; text-decoration: none;"&gt;&lt;/SPAN&gt;&lt;/A&gt;&lt;A href="https://community.nxp.com/thread/500240" target="test_blank"&gt;https://community.nxp.com/thread/500240&lt;/A&gt;&lt;/SPAN&gt;, the BLE adds the commands to an internal queue that eventually gets full and the applications are required to wait.&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;I&amp;nbsp;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.&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;How can&amp;nbsp;I&amp;nbsp;avoid this situation where this internal queue gets full?&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 03 Sep 2019 12:54:27 GMT</pubDate>
    <dc:creator>renatozapatalus</dc:creator>
    <dc:date>2019-09-03T12:54:27Z</dc:date>
    <item>
      <title>gBleOverflow when using QN9080 SDK write to attribute API.</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/940814#M7388</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P style="margin: 0cm; margin-bottom: .0001pt; text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;My&amp;nbsp;implementation consists of an altered version of&amp;nbsp;&lt;STRONG&gt;wireless_uart baremetal&amp;nbsp;&lt;/STRONG&gt;example (available in&amp;nbsp;&lt;SPAN&gt;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&amp;nbsp;UART&amp;nbsp;application using NXP Tool Box).&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt; "&gt;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&amp;nbsp;&lt;SPAN&gt;GattClient_WriteCharacteristicValue API to write the value in the connected device Gatt Server.&amp;nbsp;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;Although, after about 230 packets written, the GattClient_WriteCharacteristicValue API starts to return gBleOverflow_c. Based on this forum discussion&amp;nbsp;&lt;A _jive_internal="true" href="https://community.nxp.com/thread/500240"&gt;&lt;SPAN style="color: windowtext; text-decoration: none;"&gt;&lt;/SPAN&gt;&lt;/A&gt;&lt;A href="https://community.nxp.com/thread/500240" target="test_blank"&gt;https://community.nxp.com/thread/500240&lt;/A&gt;&lt;/SPAN&gt;, the BLE adds the commands to an internal queue that eventually gets full and the applications are required to wait.&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;I&amp;nbsp;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.&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;How can&amp;nbsp;I&amp;nbsp;avoid this situation where this internal queue gets full?&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="text-indent: 35.4pt;"&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 03 Sep 2019 12:54:27 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/940814#M7388</guid>
      <dc:creator>renatozapatalus</dc:creator>
      <dc:date>2019-09-03T12:54:27Z</dc:date>
    </item>
    <item>
      <title>Re: gBleOverflow when using QN9080 SDK write to attribute API.</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/940815#M7389</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello, &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Let me check it and investigate further on this.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards, &lt;BR /&gt;Estephania&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Sep 2019 03:19:33 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/940815#M7389</guid>
      <dc:creator>stephanie_m</dc:creator>
      <dc:date>2019-09-05T03:19:33Z</dc:date>
    </item>
    <item>
      <title>Re: gBleOverflow when using QN9080 SDK write to attribute API.</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/940816#M7390</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Could you please try decreasing the number of &lt;EM style="color: #0000ff; "&gt;gAppMaxConnections_c &lt;/EM&gt;to 2 ? The example has it by default in 16.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards, &lt;BR /&gt;Estephania&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Sep 2019 21:49:10 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/940816#M7390</guid>
      <dc:creator>stephanie_m</dc:creator>
      <dc:date>2019-09-05T21:49:10Z</dc:date>
    </item>
    <item>
      <title>Re: gBleOverflow when using QN9080 SDK write to attribute API.</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/1180538#M10360</link>
      <description>&lt;P&gt;Hello Estephania,&lt;/P&gt;&lt;P&gt;&amp;nbsp; &amp;nbsp;Am also facing the exact similar issue as explained above by&amp;nbsp;&lt;SPAN class="UserName lia-user-name lia-user-rank-Contributor-I lia-component-message-view-widget-author-username"&gt;&lt;A href="https://community.nxp.com/t5/user/viewprofilepage/user-id/69243" target="_self"&gt;&lt;SPAN class=""&gt;renatozapatalus&lt;/SPAN&gt;&lt;/A&gt;,&amp;nbsp; the only one difference in my side is we are using&amp;nbsp;GattDb_WriteAttribute write the response data to notifier. And we already configure&amp;nbsp;&lt;EM&gt;gAppMaxConnections_c&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/EM&gt;&lt;SPAN&gt;to&amp;nbsp;1.&amp;nbsp; 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&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/85032"&gt;@stephanie_m&lt;/a&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 10 Nov 2020 06:46:50 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/1180538#M10360</guid>
      <dc:creator>kishans</dc:creator>
      <dc:date>2020-11-10T06:46:50Z</dc:date>
    </item>
    <item>
      <title>Re: gBleOverflow when using QN9080 SDK write to attribute API.</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/1558247#M14017</link>
      <description>&lt;P&gt;Hi I'm facing the same issue after 2 years, I have set the max connections to 1, but that didn't help.&lt;/P&gt;&lt;P&gt;Did anyone find a solution?&lt;/P&gt;</description>
      <pubDate>Wed, 23 Nov 2022 06:38:38 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/gBleOverflow-when-using-QN9080-SDK-write-to-attribute-API/m-p/1558247#M14017</guid>
      <dc:creator>shubhs156</dc:creator>
      <dc:date>2022-11-23T06:38:38Z</dc:date>
    </item>
  </channel>
</rss>

