• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 6 replies
  • Subscribers 70 subscribers
  • Views 4395 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 206469
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Buttonless DFU Error: Enabling indications failed

jmag999

We have a couple of development units that are showing the above error in the nRF Toolbox app.  Using the nRF Connect app, the DFU dialog just goes away and the screen reverts to the normal gatt services view.  The device does not reboot and continues running.  The strange thing is that many other units with the same firmware work fine (over 300 tested).

If I manually go into nRF Connect in the Buttonless DFU service, enable indications manually and then send a request, it boots into the bootloader just fine.  It's only a problem when pushing the DFU icon at the top.

Any idea what could cause this?  It's very consistent across multiple phones (ios and android).

  • 0

    Hello,

    I haven't seen reports of this behavior before, and it's a bit strange that it fails on only 2 out of 300+ units. If possible I would suggest to attach a debugger to the failing units and place breakpoints in ble_dfu.c::on_ctrlpt_write to see if is_ctrlpt_indication_enabled is true when receiving the DFU start command. Which SDK version have you based this on?

  • 0 in reply to Vidar Berg

    Hello, I am having the same problem too. I'm using NRF Connect on iOS. I can see that the phone connects and I get the following events:

    1. BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST

    2. BLE_GAP_EVT_DATA_LENGTH_UPDATE

    3. BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST

    4. BLE_GAP_EVT_DISCONNECTED

    Then the app reports "Enabling notifications failed". I'm using a bootloader based on SDK 13.1, it's weird because it was working before. I was working on a new bootloader based on SDK 15.0, all good, then I returned to test updating the BL+SD with NRF Connect on my old bootloader and it doesn't want to connect anymore. Could it be that iOS has something cached from the newest bootloader that the old bootloader doesn't support?

  • 0 in reply to Andy

    Yes I just confirmed that. I turned off Bluetooth, restarted the phone, and tried again. Now I'm getting SD requirement not met, but I guess that's better now.

  • 0 in reply to Andy

    We noticed the same thing.  Rebooting the phone sometimes resolves the issue. We are on SDK 14 and are still seeing the issue occasionally.  The strange thing is that without rebooting the phone, some devices work and some don't.  The ios app certainly has a number of bugs, I imagine this is another one.  I think it cropped up recently because we had no issues in the past.

  • 0 in reply to Andy

    Hi Andy, I suspect this is related to attribute caching as you mentioned, and not directly related to issue reported by OP. The central may have used an invalid attribute handle cached from a previous session to enable the indication.  Cache gets cleared if you reboot or toogle flight mode/ bluetooth enable, which could explain why the rebooting the phone helped in your case.  

    For devices that support DFU it is important to implement handling for the service changed characteristic in both bootloader and application to ensure that the client performs rediscovery of the attribute table when it changes (e.g., when transitioning between app and bootloader dfu mode). 

    nRF connect on iOS doesn't display this characteristic, but you can use the same app on Android if you're unsure if you had it enabled or not.

    Service changed characteristic displayed in nRF connect on Android:

      

    More information about attribute caching can be found in BT Core spec v.5, vol. 3, Part G, section 2.5.2. 

Related