Custom service Characteristic write wrong handle on Samsung

[janR]

Hi

We have problems with Samsung tablets and phones at the moment.

We have an application with two custom services, Secure DFU Service and some standard SIG services, i.e. Battery Service and Device information Service. We are using nRF52832 with SDK14.

The problem is with custom services. We are not able to write values to a custom service characteristics. When I debug, the write event seems to reach the event handler for the custom service, but the event seems to contain the wrong handle (evt.gatts_evt.params.write.handle). The handle seems to be for the CCCD in another characteristics in the same service, instead of the value handle. Data (characteristic value) and everything else seems to be correct.

There is no problem with the SIG services, i.e. we can upload new firmware with Secure DFU.

This is only a problem with some Samsung tablets and -phones we have tested. With Apple ipad, there is no problem.

We are using nRF Connect for testing.

Is this a known problem, and if so, is there a way around?

Regards, Jan

[janR]

Hi Hung,

Now I managed to get debug out with the error present.

Write to command characteristic with Samsung SM-T550:

app: Connected to previously bonded device

app: Link secured. Role: 1. conn_handle: 0, Procedure: 0

app: NEB_OnWrite - Handle:20. Current value handle for NEB command characteristics:16

app: NBS handles: Service handle:14

app: Command char- Value handle:16 User desc handle:17 CCCD handle:0 SCCD handle:0

app: Responce char- Value handle:19 User desc handle:21 CCCD handle:20 SCCD handle:0

Write to same command characteristic with Asus Zenpad:

app: NEB_OnWrite - Handle:13. Current value handle for NEB command characteristics:16

app: NBS handles: Service handle:14

app: Command char- Value handle:16 User desc handle:17 CCCD handle:0 SCCD handle:0

app: Responce char- Value handle:19 User desc handle:21 CCCD handle:20 SCCD handle:0

app: NEB_OnWrite - Handle:16. Current value handle for NEB command characteristics:16

app: NBS handles: Service handle:14

app: Command char- Value handle:16 User desc handle:17 CCCD handle:0 SCCD handle:0

app: Responce char- Value handle:19 User desc handle:21 CCCD handle:20 SCCD handle:0

With Asus Zenpad, the application behaves correctly, with Samsung, the write is to the CCCD handler of another characteristic, the responce characteristic.

I tried to write several times, same thing happened.

But, after successful write with the Asus, I was able to do a successful write with the Samsung. Notice that the service changed indication (0x0D) occurred only with the Asus, not with the Samsung. Could this be the cause of the problem?

However, believe it or not, I am able to change behaviour of the BLE with changing code (adding and removing debug).

• I managed to get debug out with the error present by removing debug code from the NSS service (the other custom service).
• I also changed the behaviour by building a release version. Then the application behaved correctly. Only difference between release and debug version is that NRF_LOG_LEVEL is set to 0 in release, and 5 in debug. (In the release version that works, the NRF_LOG_LEVEL is set to 5). In addition "Secure DFU Service" is enabled in release.

Regards, Jan

[Hung Bui]

Hi Jan,

It's a very important information you provided: you remove and add Secure DFU service into the att table when you switch between debug and release version. It maybe not a very good idea for testing. Changing attribute table requires the application to send service changed indication. This can cause funny behaviour as you observed. You can see the Samsung phone (which do bonding) try to write to a handle 20 which is 7 from handle 13, most likely because of the missing "secure DFU service".

My suggestion is to test with nRFConnect app on the phone, because we do a att table clear everytime you disconnect. Please try not to change the attribute table. Make sure you clear bonding on both the phone and the device before testing.

If the application requires att table to be changed often, you may consider sending sd_ble_gatts_service_changed() to request the peer to re-do service discovery .