DFU OTA on iOS

[Cyril Hruscak]

Hi,

When trying to update an application using nRF Toolbox on iPad, I get the error as in this thread.

Turning Bluetooth OFF and ON does not help. On Android it works without any problems.

I'm using custom board, SDK v9.0 with SD v8.0.0 and bootloader from the SDK. The nRF Toolbox is version 2.4.

Is there something I need to set on iOS to make it work?

EDIT: According to BLE Sniffer it seems the iPad sends Reset System opcode if I understand correctly (see image).

Best regards, Cyril.

[Cyril Hruscak]

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).

[Vidar Berg]

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.

[Vidar Berg]

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.

[Cyril Hruscak]

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.

[Vidar Berg]

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.