Any guideline to config the wiced_bt_cfg_buf_pools settings

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

Hi,

From the snip code, I can find below example settings:

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 */

    { 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) */

};

If I set Medium Buffer Pool/Large Buffer Pool to 3 I got:

00023673 GKI_exception(): Task State Table

00023685 GKI_exception 65524 getbuf: out of buffers

My application only uses BLE, what is the suggestion value for the buf_pools?

I'd like to know is there any guideline to config the wiced_bt_cfg_buf_pools settings?

(for both buf_size and buf_count)

In additional, after wiced_bt_stack_init() is called, I got below messages:

00003455 GKI_create_task func=0x80171b1  id=1  name=BTU  stack=0x0  stackSize=6144

00003463 GKI_create_task func=0x801862d  id=0  name=HCISU  stack=0x0  stackSize=4096

Which means it will take at least 10K memory for creating BTU and HCISU thread.

Is it possible to reduce the memory for creating thread stack if only using BLE?

0 Likes
12 Replies
user_2112781
Level 4
Level 4
10 likes received 10 likes given 5 likes given

I have the same question, could you explain a bit more how to configure these buffer, I keep getting ​GKI_exception 65524 getbuf: out of buffers ​as well.

AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

axel.lin wrote:

In additional, after wiced_bt_stack_init() is called, I got below messages:

00003455 GKI_create_task func=0x80171b1  id=1  name=BTU  stack=0x0  stackSize=6144

00003463 GKI_create_task func=0x801862d  id=0  name=HCISU  stack=0x0  stackSize=4096

Which means it will take at least 10K memory for creating BTU and HCISU thread.

Is it possible to reduce the memory for creating thread stack if only using BLE?

The stackSize for BTU/HCISU are not configurable.

I'm wondering if it's possible to reduce these stackSize if WICED_DISABLE_STDIO.

This would be helpful for platforms with limited memory size.

0 Likes
Anonymous
Not applicable

Hi,

Stack sizes for BTU/HCISU are not configurable right now.
Though I'm not sure whether using WICED_DISABLE_STDIO will give substantial savings on memory either.

Bluetooth library gives minimal debug/info/warnings by default( optimized for library size ). so disabling STDIO probably won't help much.

These relatively bigger stack-sizes ensure that irrespective of what user does with Bluetooth-library(enables/disables the traces, logging etc. ) - library should not break with stack-overflow issues.

Thanks,
Dharam

dkumar

How about the guide line for setting wiced_bt_cfg_buf_pools?

i.e. how to calculate the required buf_size/buf_count for various cases.

0 Likes
Anonymous
Not applicable

axel.lin​ Generally speaking - the entries in wiced_bt_cfg_buf_pools map to GKI_POOL_ID_<i>

i.e. GKI_POOL_ID_0 is same as the wiced_bt_cfg_buf_pools[0]

GKI_POOL_ID_1 is same as wiced_bt_cfg_buf_pools[1] and so on...

Now, You can refer buildcfg.h ( in 3.7.0 SDK, it should be in dual_mode and low_energy sub-folders ) to get an idea of which buffers are mapped to these pools.

For example - as per dual_mode's buildcfg.h RFCOMM_CMD_POOL_ID is GKI_POOL_ID_1 ( same as wiced_bt_cfg_buf_pools[1] )

Similarly, L2CAP_CMD_POOL_ID maps to GKI_POOL_ID_1 as well. Few more searches will tell you that  GKI_POOL_ID_1 is being used for most of protocol/profile related commands.

Similarly, GKI_POOL_ID_2 ( wiced_bt_cfg_buf_pools[2] ) is being used for ACL/SDP/RFCOMM_DATA


Hope it helps.

Thanks,
Dharam

dkumar

Could you be a little bit clearer ?

I want to set the .max_attr_len to a certain value, let's say 153 and the .max_mtu_size to 153+5 = 158.

In this case what should be the values of the wiced_bt_cfg_buf_pools ? Thank you

0 Likes
Anonymous
Not applicable

marmottus

For your case - make sure that atleast one of the buffer pools in wiced_bt_cfg_buf_pools has size of more or equal to 158. Number of such buffers can vary depending on your application/use-case.

For GATT attributes - Bluetooth-stack picks the buffer from any buffer-pool which can fulfil its size-requirements. Stack will find the first buffer pool which can hold the size of the attribute-length and after that it will find the first buffer in these pools.

Let's take an example, assume that we have following buffer pools -

const wiced_bt_cfg_buf_pool_t wiced_bt_cfg_buf_pools[WICED_BT_CFG_NUM_BUF_POOLS] =

{

/*  { buf_size, buf_count } */

    { 64,       10   },      /* can be used when attribute length is less than or equal to 64 and buffers are available */

    { 158,      12  },      /* can be used by when attribute length is less than or equal to 158 bytes */

    { 360,      12  },      /* will only be used when previous buffer-pools are not available */

    { 660,      10  },      /* will only be used when previous buffer-pools are not available */

};

Now, let's say your application wants a buffer of attribute-length = 100 bytes.

So, buffers from wiced_bt_cfg_buf_pools[0] can't be used. First usable buffer pool is wiced_bt_cfg_buf_pools[1].

Once *_pools[1] get full and stack still needs a 100-byte buffer , it will search for the same in *_pools[2] .

If *_pools[2] gets full and stack still needs a 100-byte buffer it will search in *_pools[3].

If no buffers are available in any of the pools - an error will be reported.

Please note that what I explained above holds good mainly for your example( Gatt-attributes etc ). Bluetooth stack uses different buffer APIs to get buffer - it may explicitly request buffer from a particular buffer-pool or just ask for 'n' bytes of buffer( irrespective of the pool ) - this depends on the bluetooth profile/protocol being used.

Thanks,
Dharam

If the SDK can provide an API to show the run-time statistics number for buffer usage.

It'd be much easier for users/developers to debug the problem.

0 Likes
Anonymous
Not applicable

axel.lin​ We do have such API to show the run-time statistics for buffer usage and I agree that it would make developer's life bit easier while debugging Bluetooth issues - but unfortunately as of now it is not exposed.

Thanks,
Dharam

0 Likes

Then please consider to export it. This can save a lot debug time.

0 Likes

dhak wrote:

axel.lin_1746341 We do have such API to show the run-time statistics for buffer usage and I agree that it would make developer's life bit easier while debugging Bluetooth issues - but unfortunately as of now it is not exposed.

Thanks,
Dharam

It's usually too late to get run-time statistics after hitting out of buffers.

A better way to handle the problem is to improve the error message.

Just let users know which buf_siz is in shortage.

"00060909 GKI_exception 65524 getbuf: out of buffers" does not help at all.

For anyone reading this thread, there is now the API function wiced_bt_print_cfg_buf_pool_stats() for printing the buffer usage (WICED Version: Wiced_006.004.000.0061). This is useful to get an idea of the buffer usage, however I have found that I still can get the GKI_exception 65524 getbuf: out of buffers happening sometimes without the print_cfg_buf_pool_stats function showing full buffers. AxLi_1746341 says, the "GKI_exception 65524 getbuf: out of buffers" message could do with stating which buffer has been exhausted.

I have found it most useful when the wiced_bt_print_cfg_buf_pool_stats() function is placed in the management callback or in the scan callback. Be wary that anything that causes the scan callback (or especially an observer callback) to be slow to execute will rapidly lead to the "out of buffers" error!

The "Application Buffer Pools" document, Table 2 is a good starting point. It recommends,

Pool ID
Description
Size
Count
0Small buffer pool6412
1Medium buffer pool3608
2Large buffer pool7205
3Extra-large buffer pool10240

Note: The buffer size in the Large buffer pool is dependent on the MTU value supported by the application. This should be set to an
application-defined MTU value, plus an additional 12 bytes to accommodate the WICED internal header.

Run long-term tests with wiced_bt_print_cfg_buf_pool_stats() to get a feel for the buffer usage then adjust accordingly. Read the "Application Buffer Pools" document for more information.

0 Likes