Unusual behaviour with specific model host (SM-T580) with nRF52

[Musa]

Hello there,

I am working with a peripheral device that we are testing with many different devices, and have run into a very unusual issue. With a brand new Android tablet (SM-T580) we are unable to connect to our prototype device which uses an nRF52832 with S132 v4.0.2 (SDK 13.1).

In NRF Connect we got this error: Error 22 (0x16): GATT CONN TERMINATE LOCAL HOST

And looking at the debug info from the device it looks like:

What it shows is that the device on connection attempts to negotiate ATT MTU of 249B, but for some reason, the tablet requests a data length of 100 bytes. What? This doesn't happen with any of the other devices I have tried, even devices on old spec (BT 4.0).

It gets weirder, because in the ble_template app provided in the SDK (which does not have an unusual packet length), it still fails with the same error (Error 22 (0x16)):

Here's the kicker, the SM-T580 works fine with S130 (SDK 11) devices with 20B packet size.

All connection attempts were made with nRF Connect.

Any idea what's going on here?

Thanks!

[Sigurd]

Hi,

These Galaxy TAB A tablets have been reported several times of breaking/not following the Bluetooth specification.

With S132 v.3.1.0 (for nRF52) we added something called compatibility mode(compatibility mode 2) that can be enabled to still be able to connect to some of these devices that are not following the Bluetooth Specification. Since this tablet is working with S130, enabling this compatibility mode might not solve this specific issue, but it’s worth a try. You can enable it like this(You need to call the option-set function after you have enabled the SoftDevice, i.e after softdevice_enable(&ram_start);):

ble_opt_t ble_opt;
memset(&ble_opt, 0, sizeof(ble_opt));

ble_opt.gap_opt.compat_mode_2.enable = 1;

err_code = sd_ble_opt_set(BLE_GAP_OPT_COMPAT_MODE_2,&ble_opt); 
APP_ERROR_CHECK(err_code);

If this does not help, the problem is most likely that the tablet is not able to handle the DLE procedure (longer on-air data packets). In SDK 13 we have a GATT module that handles this. I suggest to use the default payload size (27), so that the DLE procedure is not initiated. By default, we set the DLE size to be equal the size of the ATT_MTU in the gatt module, so if we want to have a longer ATT_MTU but at the same time keep the default DLE size, we have to change this in the gatt module(nrf_ble_gatt.c).

In the function link_init(..) change the line

p_link->data_length_desired        = NRF_BLE_GATT_MAX_MTU_SIZE + LL_HEADER_LEN;

to

p_link->data_length_desired        = BLE_GATT_ATT_MTU_DEFAULT + LL_HEADER_LEN;

and in the function nrf_ble_gatt_init(…) change the line

p_gatt->data_length             = NRF_BLE_GATT_MAX_MTU_SIZE + LL_HEADER_LEN;

to

p_gatt->data_length             = BLE_GATT_ATT_MTU_DEFAULT + LL_HEADER_LEN;

If the issue is still there after this, try to set NRF_BLE_GATT_MAX_MTU_SIZE to 100.

[Musa]

I appreciate the detailed answer. "Galaxy TAB A tablets have been reported ... of breaking/not following the Bluetooth specification". That would explain it. It would have been nice of Samsung to mention that somewhere so I knew before I bought it. I feel obliged to at least attempt your suggested solutions, but I think I will return the tablet on principle because listing it as "Bluetooth 4.2 compatible" is false advertising.

Thanks for the help!

[Sigurd]

I have seen some report about the SM-T580 sending version exchange and length request in parallel (i.e., does not wait for the peripheral to respond before sending the next control packet). I looked some more into the problem, and it might be solved without any code changes on your part.

We have released a version 4.0.4 of the S132 SoftDevice, where we have relaxed the spec abit by allowing overlapping peer-initiated Link Layer control procedures. You can download this S132 version 4.0.4 from here.

From s132 v.4.0.4 release notes:

"The SoftDevice slave role now accepts overlapping peer-initiated Link Layer control procedures (DRGN-8623,DRGN-8975). The following LL control procedures can be executed in parallel with any other control procedure, except forthemselves: LE Ping, Feature Exchange, Data Length Update, and Version Exchange. This is done for compatibility reasons. As a result of this, BLE_GAP_OPT_COMPAT_MODE_2 has no effect"

This approach could be tested before doing any code changes. Even if the tablet is not following the BLE spec perfectly and have some bugs, it might be worth the trouble to solve this issue if your end-customers also are using these tablets to connect to your product. If v.4.0.4 does not work "out-of-the-box", try the code changes proposed in the answer above.

[Sigurd]

Note that migrating from S132 v4.0.2, to S132 v4.0.4 should be fairly simple. Replace the header files in the SDK(located in the folder SDK_folder\components\softdevice\s132\headers\) with the ones you download(located in folder s132_nrf52_4.0.4\s132_nrf52_4.0.4_API\include), and remember to flash the new softdevice hex(s132_nrf52_4.0.4_softdevice.hex) to your device.