- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
Solved! Go to Solution.
- Labels:
-
Debug
-
MasterSlave
-
Scanning-Advertising
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Perhaps you can take a look at the speed_test.c application which is similar to what you had described in your first post.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content