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

GATT timeout when reading a characteristic when notify enabled

I'm using nRF Connect for Windows with a PCA10040 DK to debug my nRF52832 product. Code is using SDK16 & S132

So I currently have one primary GATT service running with one write-only characteristic and one read-only characteristic. Both are working and I can read / write fine.

But, if I set up the read characteristic with notify=1, I get a GATT timeout in nRF Connect. Actually, the read process works initially, but if I click on the characteristic it then times out. I suspect that it's hanging trying to read or set the cccd.

I know that the nRF Connect is working because I can compile the Blinky example which works fine so it's my code at fault but after a couple of days I just can't see why.

This is how I set up the characteristic 

static void status_char_add(ble_mysvc_service_t * p_mysvc_service)
{
    uint32_t              err_code;
    ble_uuid_t            char_status_uuid;
    ble_add_char_params_t add_char_params;
    ble_uuid128_t         char_base_uuid = {BLE_UUID_MYSVC_CHAR_BASE_UUID};

    //Set the UUID
    BLE_UUID_BLE_ASSIGN(char_status_uuid, BLE_MYSVC_STATUS_CHAR);
    char_status_uuid.type = BLE_UUID_TYPE_VENDOR_BEGIN;
    err_code = sd_ble_uuid_vs_add(&char_base_uuid, &char_status_uuid.type);
    
    // Set up then add the characteristic
    memset(&add_char_params, 0, sizeof(add_char_params));
    add_char_params.uuid              = char_status_uuid.uuid;
    add_char_params.uuid_type         = char_status_uuid.type;
    add_char_params.init_len          = 16;
    add_char_params.max_len           = 16;
    add_char_params.char_props.read   = 1;
    add_char_params.char_props.notify = 1; // no problem if this is set to 0 
    add_char_params.read_access       = SEC_OPEN;
    add_char_params.cccd_write_access = SEC_OPEN;
    err_code = characteristic_add(p_mysvc_service->service_handle,
                                  &add_char_params,
                                  &p_mysvc_service->status_char_handles);

}

I'm sure I'm missing something stupid, any suggestions?

Parents Reply Children
  • OK let me clarify my setup:

    Yes this is a custom board. I haven't tried my code on a DK but there shouldn't be any difference to the BLE side, just the I/O. Also, the blinky example runs just fine on my custom board so I'd expect the same set of results running my code on the DK.

    I do also have 2 x PCA10040 DK boards. One is set up to work with NRF Connect, the other is set up for the Wireshark sniffer.

    It's definitely because there's something screwy with the Client Characteristic Configuration because it's returning an "unknown handle" . Is that set up as part of the characteristic add process? I can't see anything in the Blinky code that does anything like that.

    Edit: Sorry forgot to add the only mods to the code above is i) I removed the debug lines for clarity and ii) I just changed the name to "mysvc" as this is a public forum.

  • Hi, 

    Sorry for the late reply,

    Have you had any progress with this issue? It would be good to try it on a DK as well just to be sure. 

    But I agree that it probably is something wrong with the configuration of the characteristic. I suggest you go through this and see that everything is set up correctly.

  • No, the characteristics were all fine. I didn't bother wasting time with a DK because logic dictates it couldn't be related to hardware.

    After some hours going through my code and comparing it to the Blinky example I found that I did not have a BLE handler for BLE_GATTS_EVT_SYS_ATTR_MISSING. Added this and it now works.

  • Just wondering if you could help me understand how/why adding an event handler for a 'missing attribute' solves the problem you see when 'reading an existing characteristic'?

    Cheers

    RMV

Related