cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

RoHe_4370821
New Contributor II

Hi,

I am working with a CYW4343W and WICED Version: Wiced_006.004.000.0061

My Central application is behving as expected for most of the time, scanning for and connecting to a BLE Server, performing Service and Characteristic discovery, writing to the Server's CCCD, pairing and bonding etc. However, if I leave it to run for a few hours it will intermittently receive the BLE management callback event BTM_ENABLED_EVT with a value of WICED_TIMEOUT for p_event_data->enabled.status.

I have found that ignoring these WICED_TIMEOUT events ultimately results in one the of subsequent calles to a WICED BLE API function such as wiced_bt_gatt_send_discover() etc not returning, after which my application will hang awaiting the API call to return.

My short-term solution is to reset my device whenever the application receives BTM_ENABLED_EVT with a value of WICED_TIMEOUT. However, I would like to know what is the recommended procedure for handling such errors, please?

Also, what are the most likely causes of the BTM_ENABLED_EVT with a value of WICED_TIMEOUT, please?

Regards,

R

0 Likes
1 Solution
SheetalJ
Moderator
Moderator

For record, WICED_TIMEOUT error is generated by stack when it doesn't get response from controller chip for some command. 

Closing this thread as further discussion is going on in a technical case.

 

View solution in original post

0 Likes
13 Replies
AnjanaM_61
Moderator
Moderator

Hello,

Can you please share your application code and steps to reproduce the issue at our side?

Regards,

Anjana

0 Likes
RoHe_4370821
New Contributor II

Hello Anjana,

Unfortunately, it would be very difficult for me to publicly share our source code. Please could you give general answers to my questions:

  1. What is the recommended procedure for handling BTM_ENABLED_EVT with a value of WICED_TIMEOUT, please?
  2. What are the most likely causes of the BTM_ENABLED_EVT with a value of WICED_TIMEOUT, please?

Best regards,
Rob

0 Likes
RoHe_4370821
New Contributor II

@AnjanaM_61 

Hi,

Are you able to answer my questions, please?

Regards,
Rob

 

0 Likes
RoHe_4370821
New Contributor II

Dear @AnjanaM_61 ,

Please could you respond to my questions.

Rob

0 Likes
AnjanaM_61
Moderator
Moderator

Hi Rob,

Sorry for missing to update your thread. 

Without finding the root cause , it will be difficult to recommend any work around. 

Is it a BT only application which you are testing or any parallel wifi operation is running ?

WICED_TIMEOUT might have resulted from any of the pre BT activity. We need to figure out which exact API / BT activity is triggering the timeout . That's why we need the application to check the code flow.

1. My first suggestion is to check if this issue is happening in WICED 6.6 or not. As there was some known bugs with WICED 6.4 and its fixed in WICED 6.6 . If you still see the issue , then

1. If possible, share a simplified code to reproduce the issue at our side. 

2. Can you please check the API results of all functions are success or not in your application? From that you may get an idea if any function is not executing correctly. 

3. Can you share the device debug logs / airlogs if possible ?

4. Which peer device (server) you are using for the test ? Is it 4343W itself or any other peer apps or third party ?If then , did you try with any other BLE server devices ?

5. Are you seeing wiced_bt_gatt_send_discover  getting hang often ? What is the connection parameters you are using? Can you modify  the connection interval , supervision timeout values and see if it helps to resolve the issue? 

6. Can you please confirm if you are using enough buffer pools in wiced_bt_stack_init ? Refer hello_client example for wiced_bt_cfg_buf_pools default values 

7. Are you using 4343W EVAL board or custom board ? 

Thanks & Regards,

Anjana

0 Likes
AxLi_1746341
Honored Contributor

@AnjanaM_61 wrote:

Hi Rob,

Sorry for missing to update your thread. 

Without finding the root cause , it will be difficult to recommend any work around. 

Is it a BT only application which you are testing or any parallel wifi operation is running ?

WICED_TIMEOUT might have resulted from any of the pre BT activity. We need to figure out which exact API / BT activity is triggering the timeout . That's why we need the application to check the code flow.

1. My first suggestion is to check if this issue is happening in WICED 6.6 or not. As there was some known bugs with WICED 6.4 and its fixed in WICED 6.6 . 


The CHANGELOG.txt in 6.6.0 only mentions:
* Updated Bluetooth firmware for 4343x and 43340 platforms
* Included some defensive code to prevent attacks similar to ones described in the Sweyntooth vulnerabilities
* Fixed BT + Wi-Fi combo chip security vulnerabilities collectively known as Spectra attack (CVE-2019-15063, CVE-2020-10367 and CVE-2020-10368)

i.e. The 6.6.0 changelog does *not* mention such know bugs, so can you list the known bugs.

0 Likes
AxLi_1746341
Honored Contributor

 


@AnjanaM_61 wrote:

Hi Rob,

WICED_TIMEOUT might have resulted from any of the pre BT activity. We need to figure out which exact API / BT activity is triggering the timeout . That's why we need the application to check the code flow.



It means the user needs to handle WICED_TIMEOUT by different use case?
So what do you expect the users to do if got WICED_TIMEOUT?

0 Likes
SheetalJ
Moderator
Moderator

Hi @AxLi_1746341 ,

Ideal way to deal with such error would be to find the root cause of the issue and then try to resolve that. As @AnjanaM_61  suggested above,

1. @RoHe_4370821 can try checking if he is getting Success for every API used. 

2. You can try debugging and see where exactly you are getting the Timeout error.

3. Check if there are any simultaneous BT or other activities running.

Getting WICED_TIMEOUT is not a bug; it is an error occurred while running an application. Therefore, we cannot add it in known bug list. 

0 Likes
AxLi_1746341
Honored Contributor

@SheetalJ wrote:

Hi @AxLi_1746341 ,

Getting WICED_TIMEOUT is not a bug; it is an error occurred while running an application. Therefore, we cannot add it in known bug list. 


I'm not asking add it in known bug list.
It's @AnjanaM_61   mentioned that "As there was some known bugs with WICED 6.4 and its fixed in WICED 6.6.".
So I want to know what was fixed because the 6.6 changelog does not mention it at all.

0 Likes
RoHe_4370821
New Contributor II

Hi @SheetalJ ,

In response to your suggestions,


@SheetalJ wrote:

1. @RoHe_4370821 can try checking if he is getting Success for every API used. 

We already do this and our application will report any errors. But, I will double-check we have not missed anything.


@SheetalJ wrote:

2. You can try debugging and see where exactly you are getting the Timeout error.

I shall provide some evidence to you ASAP with debug logs, traces etc.


@SheetalJ wrote:

3. Check if there are any simultaneous BT or other activities running.

May I ask: What simultaneous activities would be illegal when we are running with a BT scan or connection, please? Are you able to direct me towards documentation that describes these things?


@SheetalJ wrote:

Getting WICED_TIMEOUT is not a bug; it is an error occurred while running an application. Therefore, we cannot add it in known bug list. 


That is good to know that it is an error rather than a bug in the stack. I'm hoping that my application is simply doing something illegal and that we may get to the bottom of it and find a solution.

Thank you.

Regards,
RH

 

0 Likes
RoHe_4370821
New Contributor II

Hi @AnjanaM_61 ,

Thank you for responding to my query.

In response to your questions:


@AnjanaM_61 wrote:

Is it a BT only application which you are testing or any parallel wifi operation is running ?


We are using the 4343W with BT and WiFi. May I ask: Are there any rules about how we manage both radio interfaces in parallel? Perhaps we are doing something illegal. Where may I find documentation regarding concurrent BT and WiFi use, please?


@AnjanaM_61 wrote:

WICED_TIMEOUT might have resulted from any of the pre BT activity. We need to figure out which exact API / BT activity is triggering the timeout . That's why we need the application to check the code flow.

I understand and thank you for the offer to examine our source code. However, we would need to arrange with our respective legal teams to provide an NDA before we could consider this. This could take some time to provide, but may be an option if we cannot find another solution. Perhaps we could revisit this if we are unable to resolve it another way.


@AnjanaM_61 wrote:

1. My first suggestion is to check if this issue is happening in WICED 6.6 or not. As there was some known bugs with WICED 6.4 and its fixed in WICED 6.6 . If you still see the issue , then

At this moment in our development cycle, we do not have the resources to perform an upgrade to WICED 6.6 as we are under pressure to deliver. I need to resolve our issues with WICED 6.4, or find acceptable work-arounds. An upgrade to WICED 6.6 would be a last resort.


@AnjanaM_61 wrote:

1. If possible, share a simplified code to reproduce the issue at our side. 

Again, we are time-pressured due to a need to deliver. If all else fails, perhaps we will have to spend the time to develop a simplified version and see what we can understand from this. However, without the behaviour of our existing application we may not see the issue. So, this could result in a lot of time spent without conclusion. I won't rule it out, but hope we can find a faster approach.


@AnjanaM_61 wrote:

2. Can you please check the API results of all functions are success or not in your application? From that you may get an idea if any function is not executing correctly. 

It is our policy to check for and report ALL return values for errors throughout our project. Of course, it is possible we have missed one and we will check this.


@AnjanaM_61 wrote:

3. Can you share the device debug logs / airlogs if possible ?

Yes, I will capture some logs to share with you in the near future. I'll come back to you with these ASAP.


@AnjanaM_61 wrote:

4. Which peer device (server) you are using for the test ? Is it 4343W itself or any other peer apps or third party ?If then , did you try with any other BLE server devices ?

Our 4343W device is acting as both Client and Server simultaneously. The issues seem to be only occurring with the Client code as far as I can tell. We use an Adroid device to connect to the Server to read/write characteristic values. We have two third-party custom bluetooth equipment that we connect the Client to: One is a Beacon and we are using the wiced_bt_ble_observe() to scan for its advertisements; The other is a discoverable sensor and we are using the wiced_bt_ble_scan() to scan for it.


@AnjanaM_61 wrote:

5. Are you seeing wiced_bt_gatt_send_discover  getting hang often ? What is the connection parameters you are using? Can you modify  the connection interval , supervision timeout values and see if it helps to resolve the issue? 

Sometimes the wiced_bt_gatt_send_discover() hangs, sometimes it is wiced_bt_gatt_le_connect(). I could alter and experiment with connection intervals and supervision timeout values if you feel strongly that this could cause such issues. However, I would not expect the stack to hang due to non-optimal values for these parameters, unless there were a known bug in the stack.


@AnjanaM_61 wrote:

6. Can you please confirm if you are using enough buffer pools in wiced_bt_stack_init ? Refer hello_client example for wiced_bt_cfg_buf_pools default values 

Yes, we have focussed on the buffer pools in the past as we did previously have issues with insufficient buffer pools. I am as sure as can be that our buffer pools are sufficient. However, other than printing out the buffer pools usage with wiced_bt_print_cfg_buf_pool_stats() and checking for the "GKI_exception out of buffers" message, I'm not sure what else can be done to verify this? Certainly I have seen that if I call wiced_bt_print_cfg_buf_pool_stats() from a timer callback after the issue of non-returning WICED API function has happened, the buffer pools printout is showing there are available buffer pools.


@AnjanaM_61 wrote:

7. Are you using 4343W EVAL board or custom board ? 

We are using our own custom-designed board.

Thank you again and I hope that after reading my responses above, that you will have some more suggestions. Meanwhile, I will collect some debug logs over the coming days to share with you.

Best regards,
RH

 

0 Likes
SheetalJ
Moderator
Moderator

A technical case is created to discuss this issue further. 

0 Likes
SheetalJ
Moderator
Moderator

For record, WICED_TIMEOUT error is generated by stack when it doesn't get response from controller chip for some command. 

Closing this thread as further discussion is going on in a technical case.

 

View solution in original post

0 Likes