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]

Hadi Deknache said:

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?

 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

 

[Hadi Deknache]

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. 

[Vidar Berg]

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?

[Hadi Deknache]

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?  

[Vidar Berg]

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.