I am trying to send TX and RX data simultaneously as fast as possible. When the RFCOMM buffer is about full, I inform peer to stop sending with wiced_bt_rfcomm_flow_control() function. The problem is that after the wiced_bt_rfcomm_flow_control() call, stack also stops providing data from the buffer, and I can't get it emptied in anyway. If I resume flow control, then peer device continues to spam the buffer again.
The reason I need to get the RFCOMM buffer emptied is that if the buffer is full, then TX does not work. Actually the whole communication gets stuck if the buffer manages to to get completely full.
I.e the question is, how can I set RX flow control on and get all the remaining data from the RFCOMM buffer?
Could you please confirm which rfcomm buffer are they referring to? Is it a buffer that is allocated and managed at the application level? If it is a stack level buffer, how you are tracking there is data in the queue if the app has flowed off the data?
The stack stops sending data to the application because the wiced_bt_frcomm_flow_control(false) tells the stack to flow off the data because the application cannot accept anymore.
Not clear on what spam the buffer means after calling wiced_bt_frcomm_flow_control(true) is called. If there is any pending once wiced_bt_frcomm_flow_control(true) is called, the stack should call the spp_port_event_cback() function with the PORT_EV_RXCHAR bit set.
You may share your project and steps to reproduce at our side.
I am using Cypress SPP lib (spp_lib.c). There the pool free count is fetched with GKI_poolfreecount(SPP_BUFFER_POOL) call. This the the pool that needs to be emptied in order to get TX work. If I call wiced_bt_rfcomm_flow_control(TRUE), then the peer device stops sending, but spp_port_event_cback() function calls stop coming also, even though there is still data according to GKI_poolfreecount(SPP_BUFFER_POOL). GKI_poolfreecount(SPP_BUFFER_POOL) never goes down, and I am never able to send anything to TX.
I understand that wiced_bt_rfcomm_flow_control(TRUE) informs stack that application can't consume more data, but it should still be possible to consume already received data somehow, without enabling data flow on air. It would be even better if rfcomm managed the buffer by itself invisible from application, but at least some solution should be available.
The basic problem here seems to be that there is a common buffer for RX and TX.