DFU failing with nRF Toolbox when updating to Samsung S10 on Android 10 (works on other devices).

[raj.labana]

We are currently having an issue with DFU failing on Samsung S10 running andorid 10. We are using nRF Toolbox for BLE and it appears to connect to the bootloader, but then fails on the second re-connect attempt to transfer the firmware.zip. I believe this issue is due to the direct advertisement report is not being received?

btsnoop_hci_success.log

btsnoop_hci_fail.log

[raj.labana]

Hi,

We are currently trying to get this working using your "nRF Toolbox for BLE" from google play store, once we can get it working from there we will then implement those fixes into our own app.

We are using:

nRF5 SDK v14.2.0
softdevice version 5.1.0
We have customised our bootloader to use direct advertising since we are not pairing with the phone

[Einar Thorsrud]

Hi,

I recomend you reconsider using direct advertising, especially since you are not pairing with the phone. When you have not paired, there is no way for the nRF to know the identity address of the phone. And therefore, when the phone changes MAC address (happened regularly, but the interval is not standardized), the phone will no longer see that the directed advertisement packets are directed to it.

[raj.labana]

Thanks for the reply. We have saved the peer connection info including the mac address to a non init memory location to pass to the bootloader. We confirm that the phone address is not changing when we do the test. We actually tried multiple times, and it always fails to reconnect once the device reboots into the bootloader. However, while it's in DFU mode, we can see the device in the list using nRF connect but cannot connect to it....

[Einar Thorsrud]

I see. I am not aware of any way to fix this on the Phone side, and the specific behavior of the BLE stack on the Android device is out of our control.

However, as mentioned using directed advertising can have several issues, and for instance, Apple explicitly states that it should not be used in its Accessory Design Guidelines. If the goal is to prevent any other device to connect to your device in bootloader mode and that is something you really need, then another and probably better approach is to use whitelisting instead. That way only the whitelisted phone is allowed to connect. But note that as long as you don't have the IRK of the phone (which you only get when pairing/bonding), you still have the problem that if the MAC address changes, it will not be accepted. So you should have a timeout in the bootloader where it reverts to application mode and allows you to start the process again.