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
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
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
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 ?
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.
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
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.
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
I will upload screenshots later today
I will upload screenshots later today
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.
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
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
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);
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
