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

NRF Connect and DFU on Iphone does not work reliably

Hello Nordic Semiconductor Team,

I have a device which uses the buttonless dfu bootloader / app design. And now i have some issues with updating the firmware with iphones and NRF connect.

If i connect with NRF connect on iphone (version 1.8.8) and start a DFU update. The app just stays on "connecting" and i can see from the LEDs on my device, that the device did not go into bootloader mode.  After some time the app says: "Device disconnected unexpectedly" . (But the device is still in the normal application, according to the leds).

If I then press the "play"/ start button again the device correctly goes into bootloader mode and the update proceeds correctly.

If i use the NRF toolbox app it always works the first time. Also on android it works fine with both nrf connect and nrf toolbox.

So is there something wrong in the current nrf connect app on iphone ? Or is there some issue with my firmware which only shows with nrf connect on iphone ? Or maybe the DFU library is different ? What DFU library version is used in the NRF connect app (NRF toolbox shows the version number, but nrf connect does not).

kind regards

Parents
  • Hi Dominik, 

    It could be an issue with the Attribute table cache on the phone. You can try to test by turn off/on Bluetooth on the phone. Or you can try to change the BLE address of the nRF device just to be sure it's not because of the Attribute table cache (it's the issue when you change the attribute table but the phone won't do service discovery to update the table).

    If that doesn't help, please capture a sniffer trace so we can investigate what happens over the air.  

  • Hello,

    I just did a sniffer trace of this issue. And it looks like it really is this issue with the attribute page.

    In the first attemt the phone seems to want to access handle 0x0089 which failes as it does not exist. (Attribute Not Found) and then NRF connect does not issue the write to the reboot characteristic and nrf connect just sits there, waiting for the bootloader.

    In the next attempt it somehow has much less attributes to explore and thus does not fail and correctly issues the write to the reboot characteristic.

    I put those two capture in the following link so you can see yourself:

    drive.google.com/.../1-kDHrfscdnkYS8jxn_GdqAS3r20WcnkZ

    So the question is now, what can i do to work around this issue ?

  • HI Dominik, 

    The sniffer trace iphone_dfu_fail2 looks a little bit strange. I can see there were a lot of CCCD characteristics has been discovered, all the way from handle 0x0011 to handle 0x007b. The error response to 0x0089 attribute not found is normal as it's the end of the table. 

    But we need to know what's your attribute table look like before and after DFU. Do you have a lot of attributes (services and characteristics) ?

    Is it reproducible to get the failed trace ? How often do you see it ? 

    According to the sniffer trace, I assume you have service changed characteristic enabled ? 

    If you test with the default bootloader and default buttonless example, do you see the same problem ? 

  • Hello,

    The device has 3 services. The Secure DFU Service, the Device Information Service and my Custom Service.

    The Custom Service has many characteristics (about 35 and some of them are big (>200bytes). But i do not think this is the issue, as i tried a test-version with only one characteristic and the problem still persists.

    With my firmware i can reproduce this error very reliably. It happens always the first time i want to update the firmware. Then NRF connect goes into timeout, and if i press play again it works once. If i then disconnect and connect and try DFU again the same happens.

    I also tried the default buttonless example, and with this it works every time. So it is very likely to be a configuration issue with my firmware, which causes NRF connect (only on iphone, android works fine) to not issue the reboot write.

    I will try some more to maybe find which config values causes this issue.

    Do you have any other ideas on what i could try ?

  • It would be easier to debug on a more simplified version of your service/characteristic. Try to test with the one with only one characteristic. 

    You can also test using the ble_app_uart and add DFU buttonless service into it, just to see if you can reproduce the issue with that. If you can then it's would be much easier here since we are more familiar with SDK's examples. 

Reply
  • It would be easier to debug on a more simplified version of your service/characteristic. Try to test with the one with only one characteristic. 

    You can also test using the ble_app_uart and add DFU buttonless service into it, just to see if you can reproduce the issue with that. If you can then it's would be much easier here since we are more familiar with SDK's examples. 

Children
  • Hello,

    i think i found what causes this issues/ found a workaround.

    My application did not use the Peermanager (because i dont use bonding, i thought i did not need it). And somehow this caused this issue of NRF connect (only on iphone) to not send the reboot write.

    You can reproduce this by disabling the peermanager in the ble_app_buttonless_dfu example (SDK15.2) and uploading it to a pca10056 device (Not sure if it happens for other SDKs or devices) with a fitting secure bootloader.

    Then, if you connect with NRF connect (on iphone) to the device and use the DFU function, it will not write to the reset characteristic (according to the sniffer) and never reset.

    Interestingly: If you use the disconnect button in NRF connect bevor hitting the DFU button (so nrf connect is forced to create a new connection just bevor trying to send the reset write) it will always work, even with Peermanager disabled.

    So for now, i will just enable/init the peermanager in my device as a workaround.

  • Hi Dominik, 

    It's quite strange that peermanager would affect the behaviour of the phone. What I can think of if any is that the service changed characteristic may not be added to the att table if you turn off peer manager and don't add the characteristic manually. 

    Android phone may work differently that it wouldn't care about service changed characteristic and do service discovery anyway. 

    If you can provide a sniffer trace (with only the DFU service ) showing the difference between Android and iOS , we can try to investigate further. 

    Regarding your custom service, it's not really recommended to have a lot of characteristic, instead you can use a common characteristic and have one extra byte to define the data type. You don't gain any more bandwidth by having multiple characteristics. Instead, it consumes more RAM, requires longer time to do service discovery (and risk incompatibility if the central device doesn't support that many characteristics)

  • Hello

    i created a sniffer trace for the nrf buttonless_dfu example with deaktivated peer_manager.

    You can find the android and the ios trace in the following google drive folder:

    https://drive.google.com/open?id=1-kDHrfscdnkYS8jxn_GdqAS3r20WcnkZ

    For android, everything works fine and on ios, the reset write is just never sent, so you do not see any reaction in the trace to me pressing the upload/ play button.

    I also put some screenshots in this folder. On android you can see the Generic Attribute with the Service Changed thing. On ios I do not see any of this, but i am not sure if this is visible on ios.

    Regarding the many characteristics. You are correct, and i noticed the problems you get with so many characteristics. But unfortunately for this product it is too late to change it. 

    I initially though it would be great to separate all the functionallity to different characteristics, similar to registers in embedded devices. But unfortunately BLE seems not be made for this. And the best case of action seems to be to use something like Serial over BLE :-/ to hide all the different actions and settings.

  • Hi Dominik, 

    Comparing "iphone_dfu_ok.pcapng" and "nrf_buttonless_no_peermanager_ios.pcapng", the reason why it failed on the iPhone is still quite mysterious to me. What I can see is that in both case you do have a service changed characteristic. But the indication was not sent. And the phone was discovering the services, and found the DFU service. But for some reason, the phone send a read request to the DFU buttonless characteristic (which it not supposed to, read is not suported), instead of a write as on the OK case. And after that a read to Handle 0x0011 and never got a response. 

    I assume you were using nRFConnect or nRFToolbox DFU profile app to test ? 


    If you can send us the source code of the buttonless application it would worth trying here. 

    Which iPhone did you use to test, and which iOS version ? 

  • Hi ,

    I uploaded the modified buttonless_dfu app to https://drive.google.com/open?id=1-kDHrfscdnkYS8jxn_GdqAS3r20WcnkZ

    If you want to build it yourself, you ofcourse have to modify the Makefile to point to your pem file fitting the bootloader. (I changed the make file to always generate the zip file for uploads via nrf connect, and always generate a flash file with merged settings)

    Yes, this was all tried with NRF Connect on Iphone and Android. The Iphone is a Iphone 6 with Software 12.1.4

Related