DFU becomes significantly slower on Android 15

[Teruyama]

When performing DFU with the same Android device + nRF Connect on the same target device, the speed becomes significantly slower on Android 15.

The attached image captures the graph of DFU performed on the same device using Pixel 6a + Android 14 or 15, and the transfer speed is clearly different.

The device in use is an nRF52840. However, we have confirmed that the DFU speed decreases on other devices as well.
Both tests used nRF Connect version 4.28.1.

Is it possible to improve the speed by changing the settings in nRF Connect or the usage of the DFU library?

[Vidar Berg]

Hello,

Is your FW based on the nRF Connect SDK or the nRF5 SDK? In case it's the latter, please ensure the 'packet receipt notification' option in nrf connect -> settings -> nRF5 DFU options is disabled. If it is necessary to troubleshoot this further, it would be helpful to have a BT sniffer capture of the DFU transfer with Android 14 and 15.

Best regards,

Vidar

[Teruyama]

We are using nRF5 SDK version 17.1.
I tried disabling PRN, but unfortunately, it did not improve the issue.

[Vidar Berg]

Hi,

I don't see any commands sent from the phone to put the device into DFU mode from the traces you posted. It's seems like the connection just times out. Are you using the Buttonless DFU service to initiate DFU over BLE, or do you use another method to enter DFU mode?

A possible explanation for the slower DFU on Android 15 could be that it is selecting a longer connection interval. But it is hard to confirm without a sniffer trace that shows the DFU transfer. 

If you had a bootloader with logging enabled, you could also monitor the BLE_GAP_EVT_CONN_PARAM_UPDATE event in nrf_dfu_ble.c

EDIT: could you try changing NRF_DFU_BLE_MIN_CONN_INTERVAL and NRF_DFU_BLE_MAX_CONN_INTERVAL to '24' in your bootloader's sdk_config.h in case the Android phone is rejected the request for 15 ms?

[Yukinori Nakamura]

When DFU starts on Android15 + nRF Connect, the capture appears to stop.
During this time, AVD_EXT_IND[Mulformed Packet] is sometimes recorded.
Also, LED1 on the nRF52 DK board stops lighting up. (It lights up again when the DFU finishes.)
The same situation occurs with devices using nRF SDK 17.1.

But the DFU process is slow but proceeds, so it looks like there is communication between the phone and the device.
Any idea why the sniffer is not working?

>Are you using the Buttonless DFU service to initiate DFU over BLE, or do you use another method to enter DFU mode?

The device uses Secure DFU.

sniffer_20241004.zip

[Vidar Berg]

Hello, 

I'm expecting to see the DFU enter command being sent before the device enters DFU mode, but I don't see that in the traces you posted. 

Could you please test the bootloader in SDK v17.1.0 again? But this time, only test the bootloader by programming the bootloader and SoftDevice. When only the bootloader and SoftDevice are programmed, the bootloader will start in DFU mode, making it easier to capture a sniffer trace since the sniffer won't need to follow the transition from the app to DFU mode. I would have tested it here if I had a Pixel 6a.

[Yukinori Nakamura]

> But this time, only test the bootloader by programming the bootloader and SoftDevice.
> When only the bootloader and SoftDevice are programmed, the bootloader will start in DFU mode, ..

Does that mean “rewrite the device program and try it, not the phone” ?

[Vidar Berg]

You will need to reprogram the device with only the bootloader and SoftDevice. Also ensure that the bootloader is configured to not require bonding. After that, you can test the DFU of the application using your phone.