Are the http_client and BT_Stack not compatible?

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

cross mob
brha_3994521
Level 3
Level 3
First like received First like given

I have an application I have written that has 2 simple functions taken from snips and samples in the wiced SDK 6,2.  I am running the code on the BCM94343W_AVN.

A link to my application is included at the bottom of this post.

After connecting to the network there are 2 function calls in the application_start()

     sendMessage();  // This function does a SSL Post of a message using the http_client

     sensor_application_init( );  // This function Initializes the BT Stack and then observes for beacons.

If these lines above are commented out one at a time, the application and each function independently works fine.

However, If they are both enabled then the http_client will break and not connect and the bluetooth will no longer observe?

I have tried increasing the application stack, but I am stuck as to why these will not work together.  The purpose of using a combo chipset was so that I could use both BT and an http client at the same time.

You can either use my code below and add your wifi info or take the snip.httpbin_org and initialize the BT Stack with something like wiced_bt_stack_init().  Of course you need to include the necessary dependencies.

Application Code:

https://drive.google.com/open?id=1lwfWolhKoksYiI-fvCGEhbhcTNgE4RCV

0 Likes
16 Replies
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

I am unable to reproduce the issue with your code in Cypress EVK. Kindly attach the terminal log and the nvram file for further debugging.

Getting the terminal output is simple enough.  Can you point me to a document or instructions for extracting the nvram file as I am fairly new to the wiced studio.  Thanks.

0 Likes

The Terminal outputs can be found here:

CypressShare - Google Drive

When I figure out the nvram I will drop the file in the same folder...

0 Likes

After turning on the logging I found a number of errors and found that the Buffer Statistics look different when I run both lines of code.  I feel like this is resource related.  I have tried boosting the buffers and I thought I was increasing the stack size, but maybe I am not doing that correctly.

Here are some of the errors I have gotten which you can see in the terminal output text file.  Failed.txt

00:00:18.898000 GKI_create_task func=0x8033a75  id=1  name=BTU  stack=0x0  stackSize=4096

00:00:18.906000 GKI_create_task thread_id failed(8), BTU!

00:00:18.912000 GKI_create_task func=0x803523d  id=0  name=HCISU  stack=0x0  stackSize=3072

00:00:30.548000 GKI_exception(): Task State Table

00:00:30.553000 GKI_exception 65524 getbuf: out of buffers

0 Likes

I think you have enabled WPRINT_WWD_DEBUG macro in wiced_defaults.h based on the terminal log. Kindly disable that along with all the other unnecessary printf/debug statements so that buffers can get allocated easily and the BT stack can run. You can refer to Re: Any guideline to config the wiced_bt_cfg_buf_pools settings for a detailed understanding about the issue and usage of buffer pools. On a different context, nvram file can be located in the 43xxx_Wi-Fi/platforms directory which is kind of redundant now for this issue since we can see the Host is running out of buffer when using both http/ble stack together.

I have previously reviewed that document and increased the buffers in an attempt to make it work.  It is interesting how the buffer stack statistics look so different in the 2 executions.  Also, is there a way to increase the BTU and HCISU stack size?  The print out in the guidelines link show larger stack sizes then my output?

I also have run with debugging turned off originally and had no difference in the result.

0 Likes

When you look at the most recent terminal output I placed in the folder named failed_new.txt you can see that the buffers are not even being used and that the BT Threads can't even initialize.  How do I address that?

were you looking for the wifi_nvram_image.h?  If so I have included it in the google drive

0 Likes

Found this discussion thread (Re: GKI Exception - out of buffers when using BLE scan and TLS for HTTP simultaneously) with people experiencing the same errors I am having.  I tried their suggestion around changing the TLS version to 1.1 but it didn't improve things.

0 Likes

Did you try reducing the http thread priority?

0 Likes

Any examples of how to do that?

0 Likes

In http_client_init() as located in 43xxx_Wi-Fi/libraries/protocols/HTTP_client/http_client.c, we are creating a worker thread with priority 5. I was suggesting you to try lowering the thread priority to 7 maybe (Don't use the default macro to change the priority, instead change it manually) and check if that helps.

I have attempted to change the Stack sizes, I tried changing the priority in the http_client.c

#define WICED_DEFAULT_APPLICATION_STACK_SIZE    (12288)

#define WICED_HCI_CMD_THREAD_STACK_SIZE (8*1024)

Changed the priority to 7 in the http_client_init()

WICED_VERIFY( wiced_rtos_create_worker_thread( &client->thread, 7, HTTP_CLIENT_STACK_SIZE, HTTP_CLIENT_EVENT_QUEUE_SIZE ) ); //WICED_DEFAULT_LIBRARY_PRIORITY

I noticed that when I initiate the BT i can't seem to get the actual stack sizes to change where they are bolded below

Start BT Stack Init

00:00:15.642000 GKI_create_task func=0x801adb5  id=1  name=BTU  stack=0x0  stackSize=4096

00:00:15.650000 GKI_create_task func=0x801c57d  id=0  name=HCISU  stack=0x0 stackSize=3072

I have tried adjusting the bluetooth buffers and more and I always get the same issue that everything works separately fine, but if both bluetooth scan and http_client are enabled, even if they don't run at the same time they break and give the output below.  I do see the buffer available counts changing with my modifications

Obtaining IPv4 address via DHCP

DHCP CLIENT hostname WICED IP

IPv4 network ready IP: 192.168.1.27

Setting IPv6 link-local address

IPv6 network ready IP: FE80:0000:0000:0000:B238:29FF:FE5E:1951

WiFi Status

WLAN MAC Address : B0:38:29:5E:19:51

MAC String: B0:38:29:5E:19:51

Resolving IP address of apidev2.fiero.team

apidev2.fiero.team is at 54.88.217.183

Start SNTP

Timestamp: 15

Stop SNTP

############################

############################

############################

Connecting to apidev2.fiero.team

Start Client

Error: failed to connect to server: 4

Start BT Stack Init

00:00:18.695000 GKI_exception(): Task State Table

00:00:18.700000 GKI_exception 65524 Unable to allocate buffer pools

00:00:18.706000 GKI_create_task func=0x8032311  id=1  name=BTU  stack=0x0  stackSize=4096

00:00:18.714000 GKI_create_task thread_id failed(8), BTU!

00:00:18.720000 GKI_create_task func=0x8033ad9  id=0  name=HCISU  stack=0x0  stackSize=3072

End BT Stack Init

sensor_application_init

00:00:29.731000

00:00:29.732000 --- Bluetooth(Pool type: A-App, I-Internal) Buffer summary ---

00:00:29.740000 Pool(size,type)   Available   In-use    Total   Max-used

00:00:29.746000 --------------------------------------------------------

00:00:29.753000 00(   0, A):           0,       0,       0,       0

00:00:29.759000 00(  64, A):          12,       0,      12,       0

00:00:29.765000 01( 660, A):           6,       0,       6,       0

Start Observe

End Observe

wait observe_semaphore

0 Likes
0 Likes

So did you attempt to execute my code on an actual device?  which EVK did you execute it on?

Can you show me the terminal response from your test?  It seems weird that there would be know issues on your execution although I feel like I shouldn't have issues on mine either.

0 Likes
lock attach
Attachments are accessible only for community members.

I am testing in CY EVK (4343w+F412), please check the log attached herewith. Changing the application stack, will have no effect in BTU, HCISU stack size which is not really configurable. This issue has more to do with the buffer availability in the host you are using since you have tried most of the application layer things to offload some memory from the host.

You tested with an unreleased sdk version so you won't see the problem.

From the log you attached:

Starting WICED Wiced_006.004.000.0028

Platform BCM94343WWCD2 initialised

Started ThreadX v5.8

WICED_core Initialized

Initialising NetX_Duo v5.10_sp3

Creating Packet pools

WLAN MAC Address : 00:A0:50:C2:40:3A

WLAN Firmware    : wl0: Jan 15 2019 20:50:27 version 7.45.98.74 (r709275 CY) FWID 01-2d50ef4b

WLAN CLM         : API: 12.2 Data: 9.10.39 Compiler: 1.29.4 ClmImport: 1.36.3 Creation: 2019-01-15 20:37:36

0 Likes