We found once the BLE transmit speed is not less than 5KB/s, the UART connection between the central device and PC will be lost.
1. Two 43438 device will be used on my test, one works as central device, another works as peripheral device.
2. Let PC connect the central device by serial port.
3. PC will send the data the central device, then the central device will send the data to peripheral device by BLE.
BTW: bt_ble_master_send_data will be used when the central device send the data to peripheral device by BLE.
When the BLE transmit speed is not less than 5KB/s, in a few minutes the UART connection between the central device and PC will be lost .
We use GDB to debug this. We can see the function relation when error happens. Please refer to gatt_write_trace.jpg attached.
The project information are below:
WICED SDK version :WICED3.6;
Moving to the WICED WiFi forum. Which 43438 Partner Module are you using in the design? Note that we do not produce 43438 eval boards for the broad market, so I will probably need to refer you to one of our regional franchised Distributors or local Cypress Sales.
We don't use any 43438 module our products.
We use the 43438 chip on our board directly, it is COB.
By BLE Transmit Speed, does this indicate that the rate at which the UART Data is being sent from the PC has a hand in this? (Do you mean the UART Data rate as the BLE transmit speed here)?
If not, if BLE Transmit Speed is separate, what exactly are you doing in project to control the BLE Speed? What is the BaudRate of the UART?
Can you please attach the project here for our reference along with steps to reproduce?
The BaudRate of the UART is 115200.
BLE speed depends on how much data the board receives from UART.
So I control the PC sending to UART,then BLE speed can be controlled too.
According to function calling trace in the debug picture attached last time,I suggest you review the code and find out why it is waiting for the "semaphore" to be free.
Because the thread is waiting for the "semaphore",so it can not go to receive the data from UART.
The picture attached is the result of gdb debug include disassembly codes.
In disassembly codes,it stopped when calling function "l2cu_no_dynamic_ccbs".
I guess when sending speed is high,it may go into "l2cu_no_dynamic_ccbs".
The test also prove that there is no problem when sending speed is 2KB/s,but problem happened quickly when speed is 5KB/s
what is the connection interval in your case? Can you please try decreasing the connection interval? May be when the UART Data coming in at a very high rate the Device is not able to pump out all the data in time, because of a high connection interval.
- Madhu Sudhan
My connection interval is 7.5 ms.I do not think it can be decreased any more.
My point is that BLE stack can drop packets when it cannot find enough resources,but it cannot just wait for something forever.
Because this may cause the task sleep and it cannot do anything else,