GATT Server - Write or Write without Response characteristic sample

[pekon94]

Hello,

is there a zephyr or nrf sample where I could check how a characteristic with write or write_withour_resp perimissions is handled by the gatt server ?

What I am trying is to find out how the gatt server can process the data written by a gatt client.

Thank you in advance

[Kenneth]

Hello,

The nus example show usage of write and the throughput example show usage of write without response:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/central_uart/README.html 
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/peripheral_uart/README.html 

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/throughput/README.html 

Hint:

Typically the GATT client can use bt_gatt_write_without_response() or bt_gatt_write(). The GATT server must add support for either or both using BT_GATT_CHRC_WRITE | BT_GATT_CHRC_WRITE_WITHOUT_RESP when calling BT_GATT_CHARACTERISTIC().

Best regards,
Kenneth

[pekon94]

Hello Kenneth,

thank you for  your assistance. 

I tried to use the throughput sample as a reference for how to process the data written by the client but was not successful.

I am using a write_callback function declared in the BT_GATT_CHARACTERISTIC() to get the attr->user_data and store in a uint16_t variable. 

Is the data written by the client temporarily stored in the user_data parameter of the bt_gatt_attr structure attr ? 

[Kenneth]

pekon94 said:

Is the data written by the client temporarily stored in the user_data parameter of the bt_gatt_attr structure attr ? 

Yes, so you must memcopy it to your own array.

Kenneth

[pekon94]

Hello Kenneth,

this is how I have used the BT_GATT_CHARACTERISTIC:

BT_GATT_CHARACTERISTIC(BT_UUID_FSR, BT_GATT_CHRC_WRITE_WITHOUT_RESP,
                       HRS_GATT_PERM_DEFAULT & GATT_PERM_WRITE_MASK,
                       NULL, write_callback, &user_dt),

and this is the write_callback function:

static ssize_t write_callback(struct bt_conn *conn, const struct bt_gatt_attr *attr,
                 void *buf, uint16_t len, uint16_t offset, uint8_t flags)
    {
        uint16_t write_data ;
        memcpy(write_data, attr->user_data, sizeof(attr->user_data));
        printk("HRS CONTROL POINT is %u\n", write_data);
        printk("HRS CONTROL POINT is %u\n", &write_data);
            printk("HRS CONTROL POINT is %u\n", attr->user_data);
            printk("HRS CONTROL POINT is %u\n", user_dt);
    }

I am testing by writing a uint16_t value, but I am not able to see the same value in the printk result.

[Kenneth]

Considering you don't really know if the erronous data is due to central or peripheral, then I suggest you capture on-air sniffer so you may check the data first:
https://www.nordicsemi.com/Products/Development-tools/nRF-Sniffer-for-Bluetooth-LE

Kenneth

[pekon94]

Thank you for this. 

I will give it a try and let you know. 

I am using my mobile phone as the central, using the nrfconnect app for android. Then I am writing different values for uint16_t data. 

[Kenneth]

Out of curiosity, what data do you write and what data do you receive when it fails? What happens if you just transfer one character?

Can you make the 'write_data ' static.

Kenneth

[pekon94]

I will upload screenshots later today

[pekon94]

Hello Kenneth,

please see the following screenshot. On the left you can see the nrfconnect bluetooth low energy (I am using an nrf52840 dongle) and on the right you can see the result of the printk from the nrf5340 GATT server. For the code, please see my previous comment.

[Kenneth]

Since you are witing a hexidecimal value I think it make more sense to also output a hexcidecimal number, e.g. %x instead of %u. I am also a bit sceptical to to the memcpy(write_data, attr->user_data, sizeof(attr->user_data)), since you are not really checking the actual length of the received data.

Kenneth

[pekon94]

Hello Kenneth,

I updated the write_callback function to check for the length of the data (found this in some sample)

    static ssize_t write_callback(struct bt_conn *conn, const struct bt_gatt_attr *attr,
                 void *buf, uint16_t len, uint16_t offset, uint8_t flags)
    {
        uint16_t *value ;
        printk("reached here and offset is %d and length is %d\n", offset, len);
    if (offset + len > sizeof(write_callback)) {
        printk("Error and length is %d \n", len);
        return BT_GATT_ERR(BT_ATT_ERR_INVALID_OFFSET);
        printk("Error\n");
    }
    memcpy(value, buf, len);
    printk("Data is %d\n",value);
    return len;
    //
    }

However, during execution of the mempcy step the script fails with:

[00:00:11.740,264] [1B][1;31m<err> os: ***** MPU FAULT *****[1B][0m
[00:00:11.740,264] [1B][1;31m<err> os:   Data Access Violation[1B][0m
[00:00:11.740,264] [1B][1;31m<err> os:   MMFAR Address: 0x0[1B][0m
[00:00:11.740,295] [1B][1;31m<err> os: r0/a1:  0x00000000  r1/a2:  0x20005fb7  r2/a3:  0x20005fb7[1B][0m
[00:00:11.740,295] [1B][1;31m<err> os: r3/a4:  0xffffffff r12/ip:  0x00001000 r14/lr:  0x00000a5f[1B][0m
[00:00:11.740,295] [1B][1;31m<err> os:  xpsr:  0x81000000[1B][0m
[00:00:11.740,295] [1B][1;31m<err> os: Faulting instruction address (r15/pc): 0x000101a2[1B][0m
[00:00:11.740,295] [1B][1;31m<err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0[1B][0m
[00:00:11.740,295] [1B][1;31m<err> os: Current thread: 0x20000bc0 (unknown)[1B][0m
[00:00:11.801,971] [1B][1;31m<err> fatal_error: Resetting system[1B][0m