• State Verified Answer
  • Replies 2 replies
  • Subscribers 68 subscribers
  • Views 2368 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 237245
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Write with response to a characteristic of the GATT Server works only with payload <= 20 Bytes

Alexey Serdyuk

Hello all,

we have currently a problem with writing to a custom chracteristics in nRF52832 with softdevice S132. When the characteristic is written, we get responses only for payloads less or equal to 20 bytes, otherwise there comes no response and no handler is called in firmware. As far as I understood, the Bluetooth standard 4.2 does allow to write characteristics within the MTU size without need of DLE or queued writes. In our application we use non standard MTU sizes and we are able to exchange the MTU, but it doesn't help. This issue we could also reproduce with the ble_app_uart example and gatttool from Bluez. Please see the attached screenshot with the reproduction steps using gatttool and the corresponding log of the nRF side (debug log is switched on). In this test we are expecting both packets to be received, however the second request with 22 byte payload is not processed. After some time board disconnects from the client.

We have also tested it with BLE scanner app for Android. It does work when one writes more than 20 bytes to the RX, but it splits write requests in 20 byte chunks automatically.

Development setup:

  • GATT Server:
    • nRF52832 (PCA10040 board)
    • S132
    • nRF5 SDK v. 15.3.0
  • GATT Client:
    • gatttool from BlueZ v. 5.48
    • Bluetooth v. 4.2 hardware (Intel 8265/8275)

gatttool:

debug log form nRF:

Parents
  • +1

    Hello,

    Can you please try to print the disconnect reason in the log for the nRF as well:

            case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected");
            uint8_t disconnect_reason = p_ble_evt->evt.gap_evt.params.disconnected.reason;
            NRF_LOG_INFO("reason: %02x", disconnect_reason);
            ...

    this hexadecimal number should correspond to one of the reasons listed in @defgroup BLE_HCI_STATUS_CODES in ble_hci.h.

    You are correct. Longer MTUs were introduced in Bluetooth 4.2, but only as an optional feature, so the devices don't need to support it. The nRF supports it, and it looks like MTU is increased from the log from the nRF. However, I suspect that the BlueZ isn't a huge fan of it, and possibly crashes when you try to send messages with more than 20 bytes. 

    If you try to program 2x nRF52832 DKs with the ble_app_uart example and ble_app_uart_c example, respectively, you should see that you can send longer strings than 20 bytes.

    Why the phone acts like that may either be because of the application (nRF Connect for Android) or that the phone doesn't support more than 20 bytes. I don't know what phone you are using.

    If you have access to another DK, I suggest you try the ble_app_uart and ble_app_uart_c example if you want to test MTU more than 20 bytes.

    Also, most later phones usually support this, but I am not sure exactly what models that support this.

Reply
  • +1

    Hello,

    Can you please try to print the disconnect reason in the log for the nRF as well:

            case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected");
            uint8_t disconnect_reason = p_ble_evt->evt.gap_evt.params.disconnected.reason;
            NRF_LOG_INFO("reason: %02x", disconnect_reason);
            ...

    this hexadecimal number should correspond to one of the reasons listed in @defgroup BLE_HCI_STATUS_CODES in ble_hci.h.

    You are correct. Longer MTUs were introduced in Bluetooth 4.2, but only as an optional feature, so the devices don't need to support it. The nRF supports it, and it looks like MTU is increased from the log from the nRF. However, I suspect that the BlueZ isn't a huge fan of it, and possibly crashes when you try to send messages with more than 20 bytes. 

    If you try to program 2x nRF52832 DKs with the ble_app_uart example and ble_app_uart_c example, respectively, you should see that you can send longer strings than 20 bytes.

    Why the phone acts like that may either be because of the application (nRF Connect for Android) or that the phone doesn't support more than 20 bytes. I don't know what phone you are using.

    If you have access to another DK, I suggest you try the ble_app_uart and ble_app_uart_c example if you want to test MTU more than 20 bytes.

    Also, most later phones usually support this, but I am not sure exactly what models that support this.

Children
  • +1 in reply to Edvin

    Hi Edvin,

    I've added this disconnect reason check and it gives me the response "BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION". So it seems to be indeed BlueZ related issue. I've also tested ble_app_uart example and our firmware with nRF Connect for Android (before it was some app from Bluepixel) and it does work properly.

    We actually used the pygatt library with gatttool backend for our integration tests. Our previous product version is based on the DA14580 and it does work with non standard MTUs and we could also write characteristics bigger than 20 bytes. We use now nRF52832 for the new version and we were a bit confused, when we faced this problem. More confusing is that the connection in gatttool dies silently in this case without any exceptions and error messages.

    We have also updated the BlueZ to the version 5.51, but the gatttool seems to be deprecated and is not maintained anymore. There is an alternative in BlueZ - bluetoothctl. It supports GATT and can be actually used instead of the gatttool. We have tested it and it works well with non standard MTUs.

    Anyways, since the issue is not nRF related it can be closed. Thank you for the support!

    Regards

Related