Custom service Characteristic write wrong handle on Samsung

RE: Custom service Characteristic write wrong handle on Samsung

Hung Bui — Thu, 16 Nov 2017 11:29:01 GMT

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 .

RE: Custom service Characteristic write wrong handle on Samsung

janR — Wed, 15 Nov 2017 15:37:27 GMT

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

RE: Custom service Characteristic write wrong handle on Samsung

Hung Bui — Wed, 15 Nov 2017 08:51:56 GMT

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.

RE: Custom service Characteristic write wrong handle on Samsung

janR — Tue, 14 Nov 2017 14:26:04 GMT

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

RE: Custom service Characteristic write wrong handle on Samsung

Hung Bui — Mon, 13 Nov 2017 15:29:30 GMT

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 ?

RE: Custom service Characteristic write wrong handle on Samsung

janR — Fri, 10 Nov 2017 15:36:56 GMT

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

RE: Custom service Characteristic write wrong handle on Samsung

Hung Bui — Fri, 10 Nov 2017 12:04:47 GMT

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 ?