How to get the 20736 BT stack status in APP layer

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

cross mob
LeCa_2156671
Level 4
Level 4
First like received First like given

Hi BCM pals,

    My team find out that, in long non-stop data tranmit test, some BCM20736 might enter some strange status such as:

1. could not receive data from its central

2. could not send data to its central

3. could not advertising

    In APP layer, we print out the log via UART, and there is no error in the APP layer.

    For example, today we have get one problem, one BCM20736 work in peripheral mode, and it could recieve data from central, but when it send data back, there is no data received by its central. After reset this BCM20736, everything goes right.

    We think that, if we could polling BCM20736 stack status in APP layer, and we could do self-reset once there is any abnormal status happened in the stack. With this process, we could improve our product much more stable.

    tks...

0 Likes
1 Solution

That depends on how much data you expect the slave to send in each connection interval (because there can be one or more connection events per interval depending on whether the MD bit is set or not). Assuming all slaves need one connection event and are exchanging one full 27 byte packet of data over the air in either direction, a round-robin scheduling will need to set aside ~2.5mS/slave. So, for 7 slaves, the minimum connection interval for each will then be around 17.5mS.

View solution in original post

0 Likes
8 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

Could it be a case of buffer overflow? I don't think it is possible to insert polling for the stack status at app layer.

Anyway to monitor CPU utilization

Check if bleprofile_sendNotification() was successful

0 Likes

Hi boont,

     Yes, we study the thread "Check if bleprofile_sendNotification() was successful", but it's a little different from what our problem now.

     We are absolutely sure that, the slave BCM20736 times and times again try to send data to the central. (the log print via UART), but there is no any data received by its central. The same time, the BCM20736 could right receive the data sent from central. Everything goes right after power reset the BCM20736.

     It's very strange, and we really do not know how to solve this problem.

     Do you have any ide strange phenomenon?

     Do you have any suggestion how to detect this abnormal status?

     Many thanks...

0 Likes

Hi Boont,

     Yes, it might be case of the txbuffer overflow.

     I have one more question:

     What is the size of the txbuffer? and what would happen if the txbuffer overflow?

     Waiting for your help, Sincerely...

0 Likes

Perhaps you can take a look at the speed_test.c application which is similar to what you had described in your first post.

0 Likes
Anonymous
Not applicable

lemancai have you taken a look at speedtest?

0 Likes

Dear Kwang,

     Yes we study the speedtest in WICED.

     In speed_test.c, the data transmition with the configuration of "lel2cap_sendConnParamUpdateReq(6, 6, 0, 700);". the data rate could up to 80K

    Here I have one more question:

     One 2073x work in central, and it could manage 7 peripherals at the same time.

     What's the recommend parameter of the lel2cap_sendConnParamUpdateReq(?,?,?,?) for each of the peripheral ?

    tks

0 Likes

That depends on how much data you expect the slave to send in each connection interval (because there can be one or more connection events per interval depending on whether the MD bit is set or not). Assuming all slaves need one connection event and are exchanging one full 27 byte packet of data over the air in either direction, a round-robin scheduling will need to set aside ~2.5mS/slave. So, for 7 slaves, the minimum connection interval for each will then be around 17.5mS.

0 Likes
Anonymous
Not applicable

lemancai is this still an issue?

0 Likes