DFU OTA on iOS

RE: DFU OTA on iOS

Vidar Berg — Wed, 02 Dec 2015 08:57:19 GMT

I have tested 6 packets per connection at 20 ms intervals without packet receipt notifications without any stability issues. I'll have to investigate this further, and update this thread when I know more.

RE: DFU OTA on iOS

Cyril Hruscak — Tue, 01 Dec 2015 07:52:35 GMT

If I reduce packet receipt notification to '2' it works. The iPad tries to send 6 packets per connection interval whereas Android can do only 3 packets. The question stays why are 6 packets per connection interval too much. The only changes I made to bootloader was to start 32MHz oscillator and use NRF_CLOCK_LFCLKSRC_RC_250_PPM_8000MS_CALIBRATION. I also removed LED and buttons from the code as they're not used on the board. Apart from that I did not change anything.

RE: DFU OTA on iOS

Vidar Berg — Mon, 30 Nov 2015 10:20:01 GMT

Thanks for the trace, the ipad appears to have started the transfer of the image, but receives operation failed from the bootloader. Thus, eventually sending the reset command. This is typically indicates that the bootloader is not able to keep up with the incoming data. That is, buffers are overflowing before they're written to flash. Have you done any modifications to the bootloader that could result in additional overhead? You can try to set the packet receipt notification to '1' to lower the throughput even more and see if that could be the cause. It would be nice to have a full sniffer trace of both Android and iOS to see what the difference is as well.

RE: DFU OTA on iOS

Vidar Berg — Fri, 27 Nov 2015 13:56:04 GMT

Unfortunately, I'm starting to run out of ideas, must be missing something. Do you have BLE sniffer to catch what's happening on air? If you have a nRF51 dongle you can use our sniffer sw here.

Another thing you can try is to connect to your application with Lighblue (third party app) and see if your ipad is able to keep the link for some time to rule out issues with protocol timing,etc.

RE: DFU OTA on iOS

Cyril Hruscak — Fri, 27 Nov 2015 08:21:09 GMT

Unfortunately I still get the same error. It must be some kind of cache problem, because when selecting device I see DfuTarg even when normal application is running (also after disable/enable of bluetooth).

RE: DFU OTA on iOS

Vidar Berg — Wed, 25 Nov 2015 17:21:54 GMT

I tried again using iOS 8.1.3, but was unable to reproduce the issue. Please make sure that packet receipt notification (number of packets) is set to '10' in settings -> nRFtoolbox. Then program s110 v8.0.0 + BL (SDK 9) to your kit, upload the hrs_s110_8_0.zip found in your toolbox app, and let me know if you still get the same error

RE: DFU OTA on iOS

Cyril Hruscak — Wed, 25 Nov 2015 13:59:51 GMT

I never used bonding with the device. I'm using iOS 8.1

RE: DFU OTA on iOS

Vidar Berg — Wed, 25 Nov 2015 12:03:54 GMT

Just to clarify, as you may know it may be listed with a different device name. Reason is that all SDK examples will use the same MAC address stored in FICR. E.g., if you had programmed the heart rate example earlier on the same device and bonded to it, ios will still see it as the same device even if your programmed a different BLE application to it.

I can't think of anything causing this. What version of iOS are you using?

RE: DFU OTA on iOS

Cyril Hruscak — Wed, 25 Nov 2015 11:20:31 GMT

The device is not listed in my devices under settings -> bluetooth. I don't use bonding anyway.

RE: DFU OTA on iOS

Vidar Berg — Wed, 25 Nov 2015 10:32:52 GMT

Please verify that you not stored any bonds with this device earlier. Go to settings -> bluetooth and clear the device if it is.