iOS reading not permitted when adding dfu charactersitics to application

[Hadi Deknache]

Hi everyone,

I have lately had some problems with my application which has different characteristics enabled, such as nus, battery service, dfu etc...

The problem I am facing lately is that when I connect to my device through my iOS application I am getting rx not permitted for nus. This occurs only when I have DFU enabled. If I would skip to initialize and add DFU my application doesn't seem to get this problem anymore. If I add it back again then the problem occurs again. Is there something weird that I am currently doing?Is there some specific order that I should initialize my device in. 

I currently initialize the DFU after have initialized all the other characteristic services.

I am currently using sdk15.0 and softdevice 6.0

[Vidar Berg]

Hello,

It sounds like it may be related to a Bluetooth feature known as attribute caching (bt spec, vol 3, part g, section 2.5.2). This feature lets the GATT client remember attribute tables across connections and thus enables it to skip service discovery on every re-connect. The problem with attribute caching, if not accounted for, arises when you make changes to an existing attribute table (adding a new service after a DFU, etc) because the ios client will continue to access the device with the old attribute handles.

Unless you know it's not attribute caching, please try to clear the cache by toggling the flight mode enable button in iOS settings (delete bonding first if bonded) before re-connecting with the DFU service. This should force the phone to perform a new discovery next time it connects to the peripheral.

[Hadi Deknache]

Hello,

First of all thank you for the immediate support!

We had the same idea that it might be something related to the attr table as you mention. 

Does this even occur when the service table is consistent between the re-connetions? Does the attr table still change?

Currently we have added all the serivces and last we have added the dfu afterwards, that's when the problem occurs that the iOS device mentions that RX not permitted. If I don't initialize the dfu service at all then the application runs without these problems.

The services are added like this:

- system_service_init

- battery service init

- nus init

- peer manager init

- and lastly dfu init

[Vidar Berg]

Ok, attribute caching shouldn't be a problem if you added the DFU service last. Is it possible to interface with these services with our nRF connect app?

[Hadi Deknache]

Yes I the nrf connect application and toolbox seem to be running smooth when connecting.

Is there someway to programmatically force update the table for the mobile phone (iOS)?

[Hadi Deknache]

Just to mention, before my characteristic services were added based on the power mode (I have 2 different modes). Based on the modes I enable some of the characteristics. However, this seem to trigger same RX not permitted problem if I enabled different characteristics in different modes or enable all characteristics always in both modes.

[Vidar Berg]

Hadi Deknache said:

Yes I the nrf connect application and toolbox seem to be running smooth when connecting.

 Did you try to replicate the RX not permitted problem with nRF connect by accessing the characteristics? It would be interesting to know if this problem is only seen with your custom app.

Hadi Deknache said:

Is there someway to programmatically force update the table for the mobile phone (iOS)?

 No, it's not possible on iOS, unfortunately. But you may consider enabling the NRF_SDH_BLE_SERVICE_CHANGED setting in sdk_config.h. This will make iOS perform discovery on every connection as long as it's not bonded with the device. For bonded devices you will have to send a service changed indication. 

[Hadi Deknache]

Hi Vidar,

Thank you for the help!

I'll try to replicate these steps in nRF connect and get back with the result.

Regarding the service changed notification I currently have enabled NRF_SDH_BLE_SERVICE_CHANGED. However, we pair our devices which I assume that this will bond the device and therefore cause this issue with RX not permitted.

When you mention that "...you will have to send a service changed indication." how is this done in the software? I assume this need to be called upon reconnecting again, because we currently pair the device and disconnect and later again connect to the device again after disconnecting.