nRF51 Legacy DFU SDK 9.0 Fails on MediaTek Android

Question

Hi, 
 
 I'm looking for help with an Android DFU failure involving an old nRF51 Legacy DFU bootloader. 
 
 Setup: 
 - Bootloader: nRF51 Legacy DFU v0.8 (SDK 9.0) 
 - Firmware package: application ZIP, 129,016 bytes 
 - Device is already in DFU bootloader mode 
 - Reconnect behavior: same MAC address on reconnect 
 - Android device: MediaTek-based phone 
 - iOS works against the same target 
 
 Problem: 
 On Android, DFU always fails right after `Start DFU` + image sizes. 
 
 Observed sequence: 
 1. Connect to device 
 2. Enable notifications on DFU Control Point 
 3. Send `Start DFU` (Op Code 1, Upload Mode 4) 
 4. Send image sizes 
 5. Device disconnects immediately with status 8 
 6. Android DFU library reports `Response not received: device disconnected` 
 7. Reconnect and retry repeats the same pattern forever 
 
 Important details: 
 - Same-MAC reconnect is confirmed. This device does not use MAC+1. 
 - iOS succeeds, which suggests the bootloader behavior itself is acceptable there. 
 - On Android, it looks like the BLE stack either delivers disconnect before the response notification, or drops the Start DFU response entirely. 
 
 What I already tried: 
 - Disabled app-side BLE scan interference 
 - Removed app-side UI abort/timeout issues 
 - Disabled MTU request 
 - Enabled PRN with value 12 
 - Confirmed `forceScanningForNewAddressInLegacyDfu` is irrelevant on this path 
 - Vendored Nordic Android DFU 2.9.0 sources 
 - Patched `LegacyDfuImpl` to catch the first disconnect after image sizes and reconnect intentionally 
 - Patched `BaseDfuImpl.readNotificationResponse()` to wait briefly for a late notification after disconnect 
 
 Result: 
 - No change. Android still never gets a usable Start DFU response after the disconnect. 
 
 Question: 
 Is this a known incompatibility between nRF51 Legacy DFU SDK 9.0 and some Android BLE stacks, especially MediaTek? 
 
 If so, is there any supported workaround besides: 
 - using iOS, 
 - using Nordic desktop tooling, 
 - or changing the device-side bootloader / DFU implementation? 
 
 I can provide full logs and the specific code patches if needed.

Aleksander Nowakowski · Answer

Hello! 
 Error 8 received as a status for disconnection is ERROR_CONN_TIMEOUT. This can happen if the device does not respond within the connection interval. The "Start DFU" command was designed to erase the flash for the new image, which, depending on the image size, may take longer time. It also looks like the bootloader is spending 100% of time on this task and doesn't bother keeping the open connection. 
 If this happens on some phones, but works on another, the issue may be the connection interval or supervision timeout. With too short interval the erase operation may not complete withing the expected time and the phone may assume the connection is dead. Some other phones may have longer interval, greater supervision timeout (how many packets a peripheral can "sleep" without replying), so the connection is kept alive for a longer time. Also, decreasing the image size may help, but that isn't something that you could easily do (would require changing the firmware), but you may use for testing in nRF Connect: 
 1. Connect in nRF Connect for Android 2. Enable notifications on DFU Control Point 3. Send "Start DFU" and set the same app size 129016 bytes or try smaller size 4. Observe if the device disconnects with larger images 5. You may also LOW_POWER or BALANCED Reqeust Connection Proirity from nRF Connect and try with larget image size, giving the target more time to erase the image. 
 If that works, you may request lower connection priority to the device in your app before you send Start DFU packet.