This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Anomalous access problems that differ for each advertising waiting time

Hi

I want to ask a few question.

When the phone sends a specific signal after connecting to the MCU, the MCU is sending data in real time.

When the power is turned on, the advertisement starts, and if immediately connect to the app and send a signal, it works without any problems.

However, if connect and send a signal 5 minutes after starting the advertising, the MCU will not send the data properly.

The return value of sd_ble_gatts_hvx is NRF_ERROR_RESOURCES.
Or "nrf_ble_gatt: sd_ble_gattc_exchange_mtu_request() returned NRF_ERROR_INVALID_STATE." is displayed in the error log.

After that, a flag that has nothing to do with it is set or disconnected, resulting in an error when reconnecting.

if(!resource_flag)
{
    do
    {
        uint32_t cnt = 0;
        err_code = ble_nus_data_send(&m_nus, send_data, &length, m_conn_handle);
        if ( (err_code != NRF_ERROR_INVALID_STATE) && (err_code != NRF_ERROR_BUSY) && (err_code != NRF_ERROR_NOT_FOUND) 
            && (err_code != NRF_ERROR_RESOURCES) )
        {
            if(err_code)  
            {
                NRF_LOG_INFO("1. err_code =  %d", err_code);
            }
               
        }
        if(err_code)  
        {
            NRF_LOG_INFO("2. err_code =  %d", err_code);
        
        }
        if(err_code == NRF_ERROR_RESOURCES)
        {
            SEGGER_RTT_printf(0,"sd_ble_gap_connect_cancel\n");
            resource_flag = true;
        }
    } while (err_code == NRF_ERROR_BUSY);
}

Also, a flag was created to wait for BLE_GATTS_EVT_HVN_TX_COMPLETE.

But I haven't seen any results.

One suspicious part is BLE_GAP_EVT_CONN_PARAM_UPDATE.

If you check the ble_evt_handler log, a BLE_GAP_EVT_CONN_PARAM_UPDATE event occurs after BLE_GATTS_EVT_WRITE.(Honestly, I don't know if it's exactly right. :)

However, if connected after a certain time, BLE_GAP_EVT_CONN_PARAM_UPDATE does not occur after BLE_GATTS_EVT_WRITE.

Upon immediate access

<info> app: on_adv_evt : BLE_ADV_EVT_FAST
<info> nrf_ble_gatt: on_connected_evt: data_length_update
<info> app: ble_evt_handler : BLE_GAP_EVT_CONNECTED
<info> app: Data len is set to 0xF4(244)
<info> app: ble_evt_handler : default == 0x3A(58)
<info> app: ble_evt_handler : default == 0x23(35) /* BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST*/
<info> app: ble_evt_handler : default == 0x24(36) /* BLE_GAP_EVT_DATA_LENGTH_UPDATE */
<info> app: ble_evt_handler : BLE_GAP_EVT_PHY_UPDATE_REQUEST
<info> app: ble_evt_handler : default == 0x22(34) /* BLE_GAP_EVT_PHY_UPDATE */
<info> app: ble_evt_handler : default == 0x12(18) /* BLE_GAP_EVT_CONN_PARAM_UPDATE */
<info> app: ble_evt_handler : default == 0x50(80) /* BLE_GATTS_EVT_WRITE */
<info> app: ble_evt_handler : default == 0x12(18) /* BLE_GAP_EVT_CONN_PARAM_UPDATE */

When connected after a certain time

<info> app: on_adv_evt : BLE_ADV_EVT_FAST
<info> nrf_ble_gatt: on_connected_evt: data_length_update
<info> app: ble_evt_handler : BLE_GAP_EVT_CONNECTED
<info> app: Data len is set to 0xF4(244)
<info> app: ble_evt_handler : default == 0x3A(58)
<info> app: ble_evt_handler : default == 0x23(35) /* BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST*/
<info> app: ble_evt_handler : default == 0x24(36) /* BLE_GAP_EVT_DATA_LENGTH_UPDATE */
<info> app: ble_evt_handler : BLE_GAP_EVT_PHY_UPDATE_REQUEST
<info> app: ble_evt_handler : default == 0x22(34) /* BLE_GAP_EVT_PHY_UPDATE */
<info> app: ble_evt_handler : default == 0x12(18) /* BLE_GAP_EVT_CONN_PARAM_UPDATE */
<info> app: ble_evt_handler : default == 0x50(80) /* BLE_GATTS_EVT_WRITE */

Thanks for reading.

  • Hi,

    I am having a bit of a problem understanding the core of the issue.

    I want to make a remark first: If you get NRF_ERROR_RESOURCES returned from sd_ble_gatts_hvx() this means that the buffers are full, and if so, the call will succeed if called again after a BLE_GATTS_EVT_HVN_TX_COMPLETE event.

    I do not immediately see how BLE_GAP_EVT_CONN_PARAM_UPDATE is related to the full buffer or should cause problems unless the new connection parameters give you too little time to send notifications as fast as you want. What were the old and new connection parameters? 

    Can you enable debug logging and upload the full log here? If you could upload the code and it runs on a DK I could test on my side. If not, please try to describe the issue in a more consistent way.

Related