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

iOS reading not permitted when adding dfu charactersitics to application

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

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

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

Reply Children
No Data
Related