GATT client error NRF_ERROR_DATA_SIZE when performing GATT write even though length is less that ATT_MTU - 3

[anusha_14]

Hello Nordic team,

I have a central client BLE application on nrf52840 that performs GATT write on another BLE server device. From BLE specifications and from various posts on Nordic Dev Zone, I understand that the BLE client can perform a write of length (ATT_MTU -3) bytes at a time. In my application, I can see that the effective MTU size is set to 23. However, if the BLE client tries to perform a GATT write of 18 , 19 or 20 bytes, a GATT client error is reported with error code 12 (NRF_ERROR_DATA_SIZE ). GATT write is only successful when I try to write data of 17 bytes or lower. 

Can you please let me know what could be the possible cause for this issue?

Note that I am using nrf5 SDK for Thread and Zigbee v4.2.0 and using softdevice S140.

Kindly let me know if you need any other details.

Thanks,

Anusha

[Simonr]

Hi Anusha

Are you able to see what exact function it is that returns the NRF_ERROR_DATA_SIZE message in your application, as that might give us a pointer to what exactly isn't the correct data size. My suspicion is that the maximum length in some init function is set to something that won't allow for bigger writes than 17 somewhere.

Also, is there a specific reason you're using the Thread and Zigbee SDK if you're only doing BLE communication?

Best regards,

Simon

[anusha_14]

Hi Simon,

Thanks for your response.

I checked which function was returning the error code as NRF_ERROR_DATA_SIZE. It is this function sd_ble_gattc_write that returns this error code. 

For GATT instance creating, I am using this macro NRF_BLE_GATT_DEF.  For GATT initialisation, I am using this function nrf_ble_gatt_init. The values of the macro NRF_SDH_BLE_GATT_MAX_MTU_SIZE is set to 23 and the macro NRF_SDH_BLE_GAP_DATA_LENGTH is set to 27 in sdk_config.h

I am using nRF SDK for Thread and Zigbee since my application needs to work either in Zigbee mode or BLE mode (not concurrently). My application checks a user variable value and depending on its value, it either starts in Zigbee mode or BLE mode.

Please let me know if you need any other details to help in solving this problem.

Thanks,

Anusha 

[Edvin]

Hello Anusha,

Simon is out of office, and his team asked if I could look into this. I just wanted to let you know that this is not forgotten. I will look into it as soon as possible.

Sorry for the inconvenience.

Best regards,

Edvin

[anusha_14]

Hi Edvin,

Thanks for updating me. I appreciate it.

Thanks,

Anusha

[Edvin]

Hello Anusha,

The only reason I can think of where sd_ble_gattc_write() returns NRF_ERROR_SIZE if it is not limited by the MTU size is if the characteristic that you are trying to write to has a size less than what you are trying to write.

Taking the ble_app_uart application as an example, the service and characteristics are set up in ble_nus_init().

If you look at where it initializes it's RX Characteristic, it sets add_char_params.max_len = BLE_NUS_MAX_RX_CHAR_LEN, so if you increase the MTU, this length will not necessarily increase.

However, in this example, it is set to NRF_SDH_BLE_GATT_MAX_MTU_SIZE - OPCODE_LENGTH - HANDLE_LENGTH = 247 - 1 - 2 = 244.

Check what your peripheral has set up as it's max length on the characteristic that you are trying to write to. If you struggle to find it, what example are you basing your peripheral on?

Best regards,
Edvin

[anusha_14]

Hi Edvin,

Thanks for your response. I am using the BLE peripheral from a 3rd party. So, I have asked them about the max length that is set in their application.

I will update you once I have an answer.

Thanks,

Anusha

[anusha_14]

Hi Edvin,

After talking to the 3rd party, I got to know that the maz MTU size for characteristic length was set to 241. When I changed NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 241 on the BLE centra, then it started to work. I think this is because there were two GATT characteristics on BLE peripheral side. BLE central was writing to one characteristic and the other characteristic that needs to be read had a size close to 241 bytes. I think it was probably the application logic on the BLE peripheral that was causing the write to fail.

I think this ticket can be closed now.

Thanks for your support.

Regards,

Anusha