BT_ATT_ERR_INVALID_ATTRIBUTE_LEN when writing to a BLE characteristic

Hello,

I'm attempting to write to a ble characteristic but when i call bt_gatt_write, I get BT_ATT_ERR_INVALID_ATTRIBUTE_LEN, I have tried to send the same command using nRF Connect application with ByteArray format and it works.

Here's my source code :

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <zephyr/kernel.h>
#include <zephyr/bluetooth/bluetooth.h>
#include <zephyr/bluetooth/conn.h>
#include <zephyr/bluetooth/gatt.h>
#include <zephyr/sys/printk.h>
static struct bt_conn *default_conn;
static bt_addr_le_t target_addr = {
.type = BT_ADDR_LE_PUBLIC,
.a = {
.val = {0x0e, 0xa0, 0x80, 0x7d, 0xcf, 0x85}
}
};
static struct bt_gatt_read_params read_params;
static struct bt_gatt_subscribe_params subscribe_params;
// K_THREAD_DEFINE(ble_thread, 1024, read_characteristic, NULL, NULL, NULL, 5, 0, 0);
K_SEM_DEFINE(ble_sem, 0, 1);
static struct bt_uuid_128 uuid = BT_UUID_INIT_128(
0xE6, 0xA9, 0xF4, 0xB4, 0x3E, 0x00, 0x0F, 0x9A,
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

prj.conf :

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
CONFIG_BT=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_HCI=y
CONFIG_BT_CTLR=y
CONFIG_BT_SCAN=y
CONFIG_BT_H4=n
CONFIG_BT_SCAN=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_PRINTK=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_MODE_IMMEDIATE=n
CONFIG_LOG_MODE_DEFERRED=y
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Btw I'm using thingy91/nrf52840

Best regards

Youssef

Parents
  • Hello,

    I think it would be helpful if you were able to show an on-air sniffer log, e.g. using nrf sniffer for BLE when working and failing. If you send two .pcapng files from Wireshark it will be easier to identify the problem in specific. An alternative may be to use the BLE app in nRF Connect for Desktop, then you can plug in an nRF52 DK to act as a central, scan&connect to a specific peripheral, list it's gatt database, and try to read and write arrays to specific handles if you want.

    I do not believe BLE have a built-in feature where a GATT client can directly request a notification from the GATT server. So I assume the bytes you share in ccc_value is some custom implementation, I guess you might try to reverse the order to see if that changes anything. But if that was the problem I would not expect that the return code was BT_ATT_ERR_INVALID_ATTRIBUTE_LEN.

    Kenneth

Reply
  • Hello,

    I think it would be helpful if you were able to show an on-air sniffer log, e.g. using nrf sniffer for BLE when working and failing. If you send two .pcapng files from Wireshark it will be easier to identify the problem in specific. An alternative may be to use the BLE app in nRF Connect for Desktop, then you can plug in an nRF52 DK to act as a central, scan&connect to a specific peripheral, list it's gatt database, and try to read and write arrays to specific handles if you want.

    I do not believe BLE have a built-in feature where a GATT client can directly request a notification from the GATT server. So I assume the bytes you share in ccc_value is some custom implementation, I guess you might try to reverse the order to see if that changes anything. But if that was the problem I would not expect that the return code was BT_ATT_ERR_INVALID_ATTRIBUTE_LEN.

    Kenneth

Children
  • Hello,

    Unfortunately, I am unable to use the nRF Sniffer for BLE because I don’t have any of the supported boards. I do have an nRF9160, but I’m unsure whether it is supported.

    However, I have a screenshot that demonstrates the communication between my nRF Connect application and my device. It shows how the value is sent when I activate notifications and send the command 0462150000 as a ByteArray request.

    Here is the picture illustrating this process:

    Could you please advise me on how to adapt my code accordingly ?

    Best Regards

    Youssef

  • Hi, 

    Youssef Elbattah said:
    Could you please advise me on how to adapt my code accordingly ?

    Sorry no (I don't know what may be the problem), do get yourself an nRF52-DK, nRF52840-DK or nRF52833-DK that you can use either as an nRF Sniffer for BLE or to run the BLE app within nRF Connect for Desktop for comparison. The BLE app provide some better control over the link and may show better what we are missing here (though a sniffer log would even be better). My wild guess would be:

    - try a different handle in case it's not +1.

    - try the opposite order of bytes to see if that helps.

    - experiment with bt_gatt_write() or bt_gatt_write_without_response() to check if there is a difference.

    Kenneth