1 of 1 people found this helpful
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.