This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Custom service Characteristic write wrong handle on Samsung

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

Parents
  • 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

Reply
  • 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

Children
No Data
Related