iOS reading not permitted when adding dfu charactersitics to application

RE: iOS reading not permitted when adding dfu charactersitics to application

Hadi Deknache — Fri, 05 Jun 2020 21:00:35 GMT

Ok, thank you for all your help!

I'll check with the app if could debug and see what might be causing this problem. Could maybe be some custom error as you mention, but very weird that the error only occur when I enable the DFU service though.

RE: iOS reading not permitted when adding dfu charactersitics to application

Vidar Berg — Thu, 04 Jun 2020 12:03:38 GMT

Thanks for confirming. Could this "RX Not Permitted" error possibly be a custom error that's raised by your application? It doesn't sound like a standard error message. I don't think this is related to attribute caching based on what you've said.

RE: iOS reading not permitted when adding dfu charactersitics to application

Hadi Deknache — Thu, 04 Jun 2020 11:53:15 GMT

Hello Vidar,

Yes, when I have enabled the DFU service then the RX not permitted seem to be triggered. If I totally remove the DFU from my application then it works without any problems and do not get this error. This seem to still also trigger after a re-connection too the same error.

I tried to remove the device totally and also the cache by turning off Bluetooth and also putting the device in airplane mode, but seem the problem will still be there when re-bonding and connecting again. However, I am able to receive nus data and send, so technically it shouldn't be any problem right? or am I wrong? because if I could send and receive data through the nus service then it is working, or is this RX Not Permitted error referring to something else?

RE: iOS reading not permitted when adding dfu charactersitics to application

Vidar Berg — Thu, 04 Jun 2020 11:43:35 GMT

The SC indication should make the receiving client (iOS) perform new service discovery and re-enable subscriptions to notification and indications.

Once you have added the DFU service, do you always get the "rx permitted" error, or does it go away next time you re-connect? Have you tried to delete the bonding information and cache as I suggested?

RE: iOS reading not permitted when adding dfu charactersitics to application

Hadi Deknache — Wed, 03 Jun 2020 13:25:07 GMT

This occur inside peer_mgr.c at PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED.

However, it later directly triggers this event :BLE_GATTS_EVT_SC_CONFIRM

I assume then that the attr table is triggering a update of the table correctly, right?

The fix you have linked to has unfortunately already been made in my project and seem.

RE: iOS reading not permitted when adding dfu charactersitics to application

Vidar Berg — Wed, 03 Jun 2020 13:04:49 GMT

[quote user="Hadi Deknache"]Ok, yes I could see the Peer managed Local DB cache fail upon reconnecting to the device. Is there any quick fix for this without having to upgrade to sdk16?[/quote]

Where is this error reported? It doesn't sound like it is related attribute caching. That said, it should be pretty straight forward to patch the service changed bug in your current project. I've tried to explain how in this thread here:

https://devzone.nordicsemi.com/f/nordic-q-a/46633/peer-manager-silently-drop-service-changed-indications-if-an-att-mtu-exchange-was-happening/204968#204968

RE: iOS reading not permitted when adding dfu charactersitics to application

Hadi Deknache — Wed, 03 Jun 2020 11:26:32 GMT

Ok, yes I could see the Peer managed Local DB cache fail upon reconnecting to the device. Is there any quick fix for this without having to upgrade to sdk16?

I made the change from RX to TX as mentioned in the other case and the same issue persisted unfortunately.

RE: iOS reading not permitted when adding dfu charactersitics to application

Vidar Berg — Wed, 03 Jun 2020 10:24:13 GMT

Hi,

[quote user="Hadi Deknache"]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.[/quote]

Thee Peer Manager module includes an API for issuing the service changed indication to all bonded peers, see pm_local_database_has_changed. However, there was a problem with the implementation in SDK 15.0.0 that could in some cases lead to the notification not being sent. This is fixed in SDK 16.0.0.

[quote user="Hadi Deknache"]The error on custom application is triggered on only subscribes to the RX when re connecting. I have tried to get the data on the RX with the arrow down and get a value on of 0x7A.[/quote]

Does the custom app raise the error when it does not receive any notifications? The problem may be related to the bug you linked to in that case

RE: iOS reading not permitted when adding dfu charactersitics to application

Hadi Deknache — Wed, 03 Jun 2020 10:00:35 GMT

Hi again,

I am trying to replicate the same steps in the mobile application on the nRF Connect app now, but is there some way to see errors when I do this or is it just to observe the value? The error on custom application is triggered on only subscribes to the RX when re connecting. I have tried to get the data on the RX with the arrow down and get a value on of 0x7A. Is it then working?

Also I checked the know issues list and saw this one:

devzone.nordicsemi.com/.../nus-sdk15-evt_comm_started-onconnect

Is it relateable to this same issue I am experiencing?

RE: iOS reading not permitted when adding dfu charactersitics to application

Hadi Deknache — Wed, 03 Jun 2020 07:21:03 GMT

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.

RE: iOS reading not permitted when adding dfu charactersitics to application

Vidar Berg — Wed, 03 Jun 2020 06:58:31 GMT

[quote user="Hadi Deknache"]Yes I the nrf connect application and toolbox seem to be running smooth when connecting.[/quote]

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.

[quote user="Hadi Deknache"]Is there someway to programmatically force update the table for the mobile phone (iOS)?[/quote]

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.

RE: iOS reading not permitted when adding dfu charactersitics to application

Hadi Deknache — Tue, 02 Jun 2020 13:20:53 GMT

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.

RE: iOS reading not permitted when adding dfu charactersitics to application

Hadi Deknache — Tue, 02 Jun 2020 13:02:58 GMT

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)?

RE: iOS reading not permitted when adding dfu charactersitics to application

Vidar Berg — Tue, 02 Jun 2020 12:57:41 GMT

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?

RE: iOS reading not permitted when adding dfu charactersitics to application

Hadi Deknache — Tue, 02 Jun 2020 12:55:01 GMT

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

RE: iOS reading not permitted when adding dfu charactersitics to application

Vidar Berg — Tue, 02 Jun 2020 12:42:07 GMT

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.