NRF51822 OTA Firmware Update

[davido]

I'm updating our bluetooth firmware and boot loader over the air from iOS and android devices. I've modified the nordic supplied update code (IOS-nRF-Toolbox project) to support updating multiple devices at once. The process works for 2-3 devices, but once you get above 2-3, if a packet gets dropped or a response gets lost, there is no mechanism to retry a missed packet. If I set a timeout to retry sending packets after getting no response, then I get a 100304 (Data Size Exceeds) error at the end of the firmware update. Any ideas what areas to look in or what needs to be done to the firmware to fix this? Is there some way to query and see whether a packet that I think was dropped was actually received? I suspect the firmware doesn't support receiving the same chunk of data twice, and so it ends up writing a resent packet twice, and the file ends up being too large.

[Vidar Berg]

Bluetooth transfers can considered a reliable transport layer as every notification packet is being acked at the link layer, and re-transmitted if not. If a packet doesn't get acked it will be considered a link loss. However, on iOS you will only get a callback when the packet is successfully queued in the output buffer, but not when it's actually transmitted on air. I suspect maybe the output buffer is overflowing in corebluetooth, and the app losses sync of the actual amount of data sent and received. I'd suggest to set the number of packets between packet receipt notifications to '1' to see if it makes any difference This will reduce the overall throughput and therefore reduce the risk of buffer overflow on the iOS side.

A sniffer trace of when it fails can also provide may also be useful to better understand what's happening (low cost sniffer if you already have a nrf51 dongle - link). Also, read the swap area in flash and compare it to the binary you tried to upload to see where it got out of sync and if duplicate data is being stored.