MQTT Software runs out of GKI blocks in Broadcom sample app on WICED SDK 3.5.2

[Anonymous]

Recently I checked out a sample app referenced on your forum that exercises, BLE, WiFi and MQTT broker communication with Watson IoT.

Sample App: BLE Central using TI CC2650 SensorTag and IBM Watson BCM4343W based IoT Quickstart...

After resolving a few build issues (detailed below), I was able to run the code on my Avnet BCM4343W IoT Starter Kit and connect with the IBM Watson IOT server

However, after roughly 2000 attributes are sent up to the IBM server (sometimes less than 2000) , the sample app eventually runs out of GKI blocks  and hangs on an Assert(). 

I am not sure if it is related to the responsiveness of the quickstart.internetofthings.ibmcloud.com server at IBM. If I disable the publish calls to MQTT, the code will receive 250000+ measurements from the SensorTag BLE device without crashing.  

Are there any known issues with the MQTT drivers in the WICED 3.5.2 platform or with the Sample App running as-is?  We will need to use these drivers and perhaps you already know of a solution.

Build Issues:

The build make file sensortag_cloud.mk was missing some include paths to make the build work with the WICED SDK 3.5.2 platform.

I had to add the following:

$(NAME)_INCLUDES   := .
$(NAME)_INCLUDES   += ../../include
$(NAME)_INCLUDES   += ../../../libraries/drivers/bluetooth_le/include
$(NAME)_INCLUDES   += ../../../libraries/drivers/bluetooth_le/BTE
$(NAME)_INCLUDES   += ../../../libraries/drivers/bluetooth_le/BTE/main
$(NAME)_INCLUDES   += ../../../libraries/drivers/bluetooth_le/BTE/WICED
$(NAME)_INCLUDES   += ../../../libraries/drivers/bluetooth_le/BTE/Components/stack/include
$(NAME)_INCLUDES   += ../../../libraries/utilities/linked_list
$(NAME)_INCLUDES   += ../../../libraries/protocols/MQTT

Without these changes, I could not get a clean build of the Sample App as downloaded from your forum

Regards,
Rob

[VikramR_26]

andrew997​

Make these changes under libraries/daemons/ wiced_bt_smartbridge_cfg.c

/*****************************************************************************

* wiced_bt_stack buffer pool configuration

*

* Configure buffer pools used by the stack

*

* Pools must be ordered in increasing buf_size.

* If a pool runs out of buffers, the next  pool will be used

*****************************************************************************/

const wiced_bt_cfg_buf_pool_t wiced_bt_cfg_buf_pools[WICED_BT_CFG_NUM_BUF_POOLS] =

{

/*  { buf_size, buf_count } */

    //{ 64,       4 },      /* Small Buffer Pool */

    { 64, 16   },      /* Small Buffer Pool */

    { 360,      4 },      /* Medium Buffer Pool (used for HCI & RFCOMM control messages, min recommended size is 360) */

    { 360,      12  },      /* Large Buffer Pool  (used for HCI ACL messages) */

    { 360,      0 },      /* Extra Large Buffer Pool - Used for avdt media packets and miscellaneous (if not needed, set buf_count to 0) */

};

[Anonymous]

Thanks for your quick response... well.. increasing the buffer pool eliminated one error, but now it fails consistently at _nx_packet_data_append() in a memcpy call, with the offending address shown in BFAR as 0xefefefef when the exception traps.  The PC is always the same 0x80600fe (within memcpy).

I don't believe I have access to the NetX library source code, but I would be curious what pointers are initialized to 0xefefefef.  It seems there is a path where some pointer in the netx driver is not being initialized.

Here are 2 more crash instances...

[AxLi_1746341]

vik86 wrote:

andrew997

Make these changes under libraries/daemons/ wiced_bt_smartbridge_cfg.c

/*****************************************************************************

* wiced_bt_stack buffer pool configuration

*

* Configure buffer pools used by the stack

*

* Pools must be ordered in increasing buf_size.

* If a pool runs out of buffers, the next  pool will be used

*****************************************************************************/

const wiced_bt_cfg_buf_pool_t wiced_bt_cfg_buf_pools[WICED_BT_CFG_NUM_BUF_POOLS] =

{

/*  { buf_size, buf_count } */

    //{ 64,       4 },      /* Small Buffer Pool */

    { 64, 16   },      /* Small Buffer Pool */

    { 360,      4 },      /* Medium Buffer Pool (used for HCI & RFCOMM control messages, min recommended size is 360) */

    { 360,      12  },      /* Large Buffer Pool  (used for HCI ACL messages) */

    { 360,      0 },      /* Extra Large Buffer Pool - Used for avdt media packets and miscellaneous (if not needed, set buf_count to 0) */

};

Can you provide documentation for configuring the buffer poll?

The developers needs to know how to properly set the buf_size and buf_count

settings in various scenarios rather than by *guess* the settings.