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

[Hung Bui]

Hi Jan,

Did you do any DFU update that involve a change of the attribute table ? How do you verify that the handle value was not correct ?

When you do service discovery using nRFConnect do you see the correct attribute table ? If you test with a stock example (e.g ble_app_uart) do you see the problem ? ble_app_uart also use customer service.

Note that the phone may automatically enable notification (write to CCCD), could that be the case when you receive the event ?

[janR]

Hi Hung

I did in fact made an update that added a custom service with one characteristics.

I verified the handle problem by first placing a breakpoint in the "onWrite" event handler (BLE_GATTS_EVT_WRITE) after the check of the handle ( if (p_evt_write->handle == p_nbs->commandHandle.value_handle) ) The code never hits the breakpoint when the error is present. The breakpoint is hit when using other devices than Samsung.

If I move the breakpoint before this, the breakpoint is hit, but then the handler is wrong. It could of course be that the write to the CCCD handler is intended, but the value handler should be written anyway?

The attribute table appears correct in nRF Connect.

I have, as you recommended, tested with ble_app_uart, and this application behaves correct on Samsung.

Anyway it is strange that I only see the problem with Samsung. Now I also have tested with an old Lenovo tablet, and also an old HANNspree tablet (both running Android). Both are working.

It is maybe worth mentioning that both the Samsung tablets was connectd to the application before the service was added. I now suspect that there is some cached data in the two Samsungs that I can't get rid of (I have tried unbounding). Could this be true?

Regards, Jan

[Hung Bui]

Have you made sure NRF_SDH_BLE_SERVICE_CHANGED set = 1 in your application (both the old and new) ?

I also suspect attribute table was cached on the phone. You may want to restart the phone to make sure it would erase cache. But you mentioned that nRF Connect app running on the phone show the correct att table ? If you add a log to UART to print p_evt_write->handle , when you try to write to the characteristic from NRFConnect, which handle ID you would receive ? and how would it compare to the correct handle ID ?

[janR]

I have verified that NRF_SDH_BLE_SERVICE_CHANGED = 1 in both old and new application. Tablet is restarted (and turned off and then on). It did not help. Bonding is erased, bluetooth is turned on and off. No help

I now have added debug out to the cusom services. But this made the behaviour even stranger; now it started to work again. The only change was adding debug code.

Could the behaviour be due to a timing issue somewhere?

Here is the debug out:

<info> app: Connected
<debug> app: BLE connected
<debug> app: Link secured. Role: 1. conn_handle: 0, Procedure: 1
<debug> app: NEB_OnWrite - Handle:13. Current value handle for NEB command characteristics:16
<debug> app: NSS_OnWrite - Handle:13. Current value handle for NSS command characteristics:24
<debug> app: NEB_OnWrite - Handle:16. Current value handle for NEB command characteristics:16
<debug> app: NSS_OnWrite - Handle:16. Current value handle for NSS command characteristics:24
<info> app: Disconnected
<debug> app: BLE disconnected

<info> app: Connected
<debug> app: BLE connected
<debug> app: Connected to previously bonded device
<debug> app: NEB_OnWrite - Handle:16. Current value handle for NEB command characteristics:16
<debug> app: NSS_OnWrite - Handle:16. Current value handle for NSS command characteristics:24

<info> app: Disconnected
<debug> app: BLE disconnected

First connection is right after erasing chip, programming softdevice, and starting application. I write to one of the characteristic (with value_handle 16) in one of the custom services I then disconnect, connect, and write to the same characteristics again. Then I disconnect.

I noticed that before the first write, a write to an unknown handle (13) is done. I don't know what this handle belongs to. It is not one of the custom characteristics. I also noticed that the first connection is different than the second: 1st: app: Link secured. Role: 1. conn_handle: 0, Procedure: 1 2.nd: app: Link secured. Role: 1. conn_handle: 0, Procedure: 0 Procedure is 1 in the first, and 0 in the second. What is actually this? And "Connected to previously bonded device" appears on the second connection. I have not asked for any bonding, so this must be done automatically somehow. However, it is possible that this has nothing with the behaviour to do.

When I build a release of the code (without debug), the problem is still there; I can't write commands to the device probably because the handle is wrong.

I know this could be due to too small task stacks (I'm using FreeRTOS), but the task stacks has plenty of room. I also have the configCHECK_FOR_STACK_OVERFLOW set to 2, without finding anything.

Regards, Jan

[Hung Bui]

Hi Jan,

Please specify what's the different between your debug and release versions ?

Handle ID = 13 = 0x0D is the service changed indication, so it's normal that the phone write to that characteristic.

Procedure is the indication on how the link is encrypted, look for pm_conn_sec_procedure_t you will find it.

And yes, bonding was done automatically, I'm not sure why, could be that your device has HID characteristic. Or if you connect using Bluetooth setting , the phone will automatically bond.

Please try to find a way to debug with the release version, simply add some printf shouldn't cause the change in the behaviour of the handle id to be set.