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

Read/write chracteristics by handle value without service discovery.

ble_app_wbh.zipble_app_wbh_c.zip

Hi Nordic,

I am trying an application where both central and peripheral devices are based on nRF52.

I have to create custom services and characteristics for the same.

These are going to be battery operated and power sensitive devices.

Hence as part of power saving we want to avoid service discovery process at central side.

Our handle values are more or less going to locked once development is over hence we do not see ant reason to have service discovery either.

I have attached sample app of my central and peripheral device here both written for nRF52840 with SDK v15.0.0.

While I am able to connect my central device with peripheral device but I am getting error 17 when I try to read by handle directly.

The final intent is to be able to read/write chars by handle value.

Can you pin point the mistakes I am making or perhaps share a similar working example which can help with my purpose.

Cheers,

Shishir

Parents Reply Children
  • Hi Hung,

    In central application ble_app_wbh_c file main.c function ble_evt_handler -> case BLE_GAP_EVT_CONNECTED is the place where I call the handle read operation in place of service discovery.

    err_code = ble_common_read_by_handle(p_gap_evt->conn_handle, BLE_FAS_HDL_OLD_ID_RANDOM_NUMBER_CLEAR);
    APP_ERROR_CHECK(err_code);

    Internally this API is calling

    err_code = sd_ble_gattc_read(conn_handle,
    handle,
    0);

    This is the place where I am getting error 17.

    Also The handle value is 19 and correct.

    I'll send my nRF debug logs.

    Also I'll try to setup for sniffer and send the logs ASAP.

    Cheers,

    Shishir

  • Hi Shishir, 

    Error 17 means NRF_ERROR_BUSY most likely there was other procedure already on going. Do you have other code or repetitive code that call read request and write request ? 

    If you put a delay and then retry do you have the same issue ? 

  • Hi Hung,

    Below are my peripheral and central application individual logs.

    You can see that as soon as connection gets establishes central device attempts a read request on handle 19 and error is returned as error 17.

    Its happening even if both devices are reset and first time connection/comm happens.

    I am no more using APP_ERROR_CHECK against this error to stop micro getting reset.

    Logs from Peripheral device:

    <info> app: Heart Rate Sensor example started.
    <info> app: Fast advertising.
    <info> app: Connected.
    <info> app: PERIPHERAL: Random Number Sent[0x0000], Calculated Cipher[0x0000]
    <info> app: GATT ATT MTU on connection 0x0 changed to 247.
    <info> app: advertising_init -> err_code [0]
    <info> app: services_init -> err_code [0]
    <info> app: ble_fas_init -> err_code [0]
    <info> app: ble_fas_init -> err_code [0]
    <info> app: ble_fas_init -> err_code [0]
    <info> app: ble_fas_init -> err_code [0]
    <info> app: services_init -> err_code [0]
    <info> app: Heart Rate Sensor example started.
    <info> app: Fast advertising.
    <info> app: Connected.
    <info> app: PERIPHERAL: Random Number Sent[0x0000], Calculated Cipher[0x0000]
    <info> app: GATT ATT MTU on connection 0x0 changed to 247.


    ================================================================================================

    Logs from Central device:


    <info> app: Heart Rate collector example started.
    <info> app: Starting scan.
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [14:4F:D7:20:1B:9F]
    <info> app: [00]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [09:DB:61:25:4F:6D]
    <info> app: [03]
    <info> app: [EC:02:AE:C8:0D:16]
    <info> app: [01]
    <info> app: Address match send connect_request.
    <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
    <debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
    <info> app: Connected.
    <info> ble_mgmt_c: Reading by Handle 19, error[17]
    <debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 247 bytes.
    <debug> nrf_ble_gatt: Updating ATT MTU to 247 bytes (desired: 247) on connection 0x0.
    <debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
    <info> app: GATT ATT MTU on connection 0x0 changed to 247.
    <debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
    <debug> nrf_ble_gatt: max_rx_octets: 251
    <debug> nrf_ble_gatt: max_tx_octets: 251
    <debug> nrf_ble_gatt: max_rx_time: 2120
    <debug> nrf_ble_gatt: max_tx_time: 2120
    <info> app: Data length for connection 0x0 updated to 251.

  • Instead of doing a read right after connection, could you try to do it after the MTU exchange is finished and the Data Length extension is updated ? 

    Have you tried to add a delay or retry doing read ? 

    If you want to do the read command right after the connection, you would need to make sure there is no other process at the same time (for example MTU update, DLE update) 

  • Hi Hung,

    Sorry for the delayed response but I tried putting 1 - 5 sec delay before and after read request for handle number but still the same error. From the logs it looks like MTU size change is being made after my handle read request so tries delay after read handle request also. still I am getting the same error.

    Can you point me any working sample application where we do a read by handle or write by handle without service discovery.

    Cheers,

    Shishir

Related