To whomever this may concern,
We are investigating a BLE firmware-update compatibility issue affecting a legacy Nordic nRF51 DFU bootloader on a subset of iPads.
We are seeking guidance on whether there are known CoreBluetooth or Bluetooth-controller differences across recent iPad hardware that could affect reconnection to Bluetooth LE connectable directed advertisements.
Background
Our accessory uses a legacy Nordic nRF51 DFU flow:
- The iPad is connected to the accessory’s normal application firmware.
- The app requests entry into DFU mode.
- The accessory disconnects normally.
- The accessory restarts into its bootloader.
- The bootloader sends connectable directed advertisements targeted at the iPad that initiated DFU.
- The iPad is expected to reconnect, after which the firmware transfer begins.
Observed behavior
On working iPads, the BLE trace shows:
Application disconnect
→ accessory begins connectable directed advertising
→ iPad sends BLE connection indication
→ bootloader connection succeeds
→ DFU begins
On affected iPads, the trace shows:
Application disconnect
→ accessory begins the same connectable directed advertising
→ no connection indication from the iPad
→ DFU cannot proceed
The accessory is advertising to the current resolvable address of the connected iPad. The bootloader starts directed advertising at nearly identical timing in both working and failing traces, approximately 456 ms after disconnect.
The initial disconnect is normal in both cases:
LL_TERMINATE_IND / Remote User Terminated Connection / reason 0x13
The problem occurs only after the accessory begins directed advertising.
It seems like the iPad might be able to receive and listen to directed advertisement, however it seems to be unable to send back a connection indication.
Hardware correlation observed so far
We observed a correlation with Bluetooth controller vendor information visible in our BLE captures:
FORMAT FOR FOLLOWING LINES
Result -> Example device -> Observed controller vendor
DFU succeeds -> iPad Air, 5th generation -> Broadcom
DFU succeeds -> Other tested iPads, including one iPad with an A16-class platform -> Broadcom
DFU fails -> One affected iPad with an A16-class platform -> MediaTek
We want to be careful not to overstate this result:
We have tested only one affected MediaTek-based iPad so far. The model string is MD3Y4LL/A and its current iOS version 26.6.1. The functioning Broadcomm iPads A16 we have tested that did not fail DFU process have model string MD7F4KN/A.
The other iPad models we tested DFU on (which were all successful, albeit none of them were MediaTek chips, they were all Broadcomm) were: MRJN2KN/A, MM9C3KN/A, MQ6J3KN/A, MM6T3KN/A (the latter with iOS 26.6.1 as well, suggesting it is not necessarily an iPad OS version issue)
We have not found a second MediaTek-based iPad to determine whether the behavior reproduces across that hardware.
We initially suspected that recent non-cellular iPads might consistently use MediaTek, but this was disproved by the iPad Air, 5th generation we tested (MM9C3KN/A): it had no cellular connection and used Broadcom, and DFU worked normally.
Therefore, we do not conclude that the issue is caused by MediaTek hardware. We only see a correlation worth investigating.
What we have ruled out
The target firmware image is not involved; failure occurs before any firmware data is transferred.
The accessory reaches bootloader mode and sends directed advertisements at the expected time.
The iOS Nordic DFU library already calls CoreBluetooth’s normal reconnect API:
centralManager.connect(peripheral, options: nil)
iOS does not expose an API allowing an app to create or send a raw Link Layer CONNECT_IND; therefore the application cannot directly work around controller-level connection behavior.
The affected iPad does not provide a normal scanner/discovery callback for this directed bootloader advertisement, so matching by name or service UUID is not available as an application-layer workaround.
Questions
.
- Are there known CoreBluetooth, iPadOS, or Bluetooth-controller differences that can affect handling of BLE connectable directed advertisements, particularly when an accessory directs advertisements to a central using a resolvable private address?
.
- Is there a recommended CoreBluetooth pattern for reconnecting to a known peripheral after it restarts into a legacy bootloader that uses directed advertising?
.
- Does
CBCentralManager.connect(_:options:) queuea pending connection request that should be serviced when a matching directed advertisement is received? If so, are there circumstances in which this behavior differs by iPad hardware or controller implementation?
.
- Is there any public diagnostic information, entitlement, or supported API that could help us determine why a pending CoreBluetooth connection request does not result in a connection attempt in this scenario?
.
- Does Apple recommend a specific compatibility approach for legacy BLE DFU bootloaders that use directed advertising, beyond updating the accessory firmware to use ordinary undirected advertising?
.
We can provide packet captures from both the working and failing cases, including timestamps, directed-advertisement target addresses, and the absence/presence of the subsequent connection indication.
Thank you for any guidance on whether this is expected behavior, a known compatibility limitation, or if there is anything we could try on our end to hopefully resolve this issue.
