Hello,
We are using SDS 6.0.0, SDK 5.2.0 on an nRF51822. Our application is a data logger that can collect up to 128Kbytes of data. Users can connect to the data logger and use our iOS application to offload the data. We are encountering a problem where the call to the function sd_ble_gap_conn_param_update is returning NRF_BUSY. What is happening is that the users are connecting to the data logger and initiating a data offload prior to the first time the connection parameter update timer fires (5 second timer). The data offload attempts to move the up to 128Kbytes of data over to the mobile as fast as possible, so I am jamming packets onto the radio as fast as it will let me.
I suspect when this happens it is possible we have jammed enough data onto the radio to transfer to the host that the radio can not accommodate the sd_ble_gap_conn_param_update request. This causes the code in module ble_conn_parms.c function update_timeout_handler to call the m_conn_params_config.error_handler function which in turn triggers an ASSERT.
In the case of NRF_BUSY as an error code, I'd prefer not to ASSERT. Would it be reasonable to check for NRF_BUSY as a return code and if so allow update_timeout_handler to exit without calling the error handler. Then allow the next BLE_GAP_EVT_CONN_PARAM_UPDATE event to restart the update timer?
I'm asking this question out of an abundance of caution. I'm just days away from cutting this FW over to production and I don't want to make a change that may cause subtle problems I don't catch in my bench testing, but causes problems for our customers.
Thanks, John
