Problems with data being deposited into the Bluetooth transmitter queue

I keep calling the nrf_ble_gq_item_add function in a loop, sending 244 bytes of data with each call. It behaves well when called every 0.6s, but if the interval is changed to 0.3s, an error pops up after a variable number (1-20) of runs. the error is:app: ERROR 9 [NRF_ERROR_INVALID_LENGTH].

Did I miss something in the initialization? Or is this function not to be called repeatedly in too short a time?

  • Hi,

    What parameters are you using for the call? Since some parameters use pointers, please make sure you are not re-using any of those too quickly, which could lead to faulty values (which again might lead to all sorts of problems.)

    Apart from that, without full context it is hard to tell what may be going on. Please share enough code for us to see the full context of how you use the function, to be able to say more.

    Regards,
    Terje

  • Hi,

    Here's the code and parameters for the call

    write_req.type = NRF_BLE_GQ_REQ_GATTC_WRITE;
    write_req.error_handler.cb = gatt_error_handler;
    write_req.error_handler.p_ctx = p_ble_uarts_c;
    write_req.params.gattc_write.handle = p_ble_uarts_c->handles.uarts_rx_handle;
    write_req.params.gattc_write.len = length;  //244bytes
    write_req.params.gattc_write.offset = 0;
    write_req.params.gattc_write.p_value = p_string;
    write_req.params.gattc_write.write_op = BLE_GATT_OP_WRITE_REQ;
    write_req.params.gattc_write.flags = BLE_GATT_EXEC_WRITE_FLAG_PREPARED_WRITE;
    nrf_ble_gq_item_add(p_ble_uarts_c->p_gatt_queue, &write_req, p_ble_uarts_c->conn_handle);

    and here's my connection parameters

    static ble_gap_conn_params_t m_conn_param =
    {
        .min_conn_interval = MSEC_TO_UNITS(NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL, UNIT_1_25_MS), // min 7.5ms
        .max_conn_interval = MSEC_TO_UNITS(NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL, UNIT_1_25_MS), // max 30ms
        .slave_latency = NRF_BLE_SCAN_SLAVE_LATENCY,
        .conn_sup_timeout = MSEC_TO_UNITS(NRF_BLE_SCAN_SUPERVISION_TIMEOUT, UNIT_10_MS),
    };

  • Sorry, after a period of experimentation, I found that the problem lies elsewhere in the system

Related