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 ? 

[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

[pekon94]

I also noticed that the the attr->handle that gets printed is 0 (while when testing the write using the dongle I get "Attribute value written, handle: 0x1A, value (0x): 11").

The flags print as 2.

The code I am using to print these details is:

printk("reached here, offset is %d , length is %d , handle is %x and flags is %d\n", offset, len, attr->handle, flags);

[Kenneth]

I suggest to look and compare with the examples in zephyr and ncs, and hopefully you will find the culpit. 
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/samples_bl.html 
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/index.html 

[pekon94]

Hello Kenneth,

sorry for this but I found out I was doing stupid errors:

• I had not initialized the pointer (this was causing the last error I uploaded)
• I was not printing the value pointed by the pointer but the address stored in the pointer. 

I have fixed both and now it works fine. 

Thanks for your support. 

[lcj]

Can you show the code you used?