Android-DFU-Library
Android-DFU-Library copied to clipboard
Samsung Devices with Android Version 13-14 changes Address on every Connection
Version
2.4.0
Ask the question
I have been working with your DFU library in my Android Project with Nordic Devices, I recently noticed an issue with firmware update that with samsung devices with version 13, 14. I am getting Error 133 everytime, that was not the case with other devices with same android version or even older version samsung devices. When I looked into the issue I found out that Samsung device changes address everytime when it is connection to peripheral. In my application when i connect with my application logic to enter device into dfu and after that using DFU library when library connects again to update firmware than due to change in address of device process wouldn't complete as we have logic that address should be same. So i am stuck here as it is specifically seen in samsung phones with android version 13,14, even older versions of samsung it was working fine.
Relevant log output
Logs on firmware side
First, peer addr is addressed used by application to enter device into dfu mode, second peer_mac is during start of dfu process from library.
Motorola g73
peer addr:148.208.229.131.66.99.
prev:0
error Code:0
Stack Ver:152
pkt_handle 16
dfukey:773031752
evt_id 16
SDK_V11 0
peer_mac148.208.229.131.66.99.
Samsung Galaxy F22
eer addr:10.157.33.11.255.103.
prev:0
error Code:0
Stack Ver:152
pkt_handle 16
dfukey:-1862726602
evt_id 16
SDK_V11 0
peer_mac57.113.125.70.22.107.
conn_interval 36
evt_id 17
after switch 0
pkt_handle 16
dfukey:-1862726602
evt_id 16
SDK_V11 0
peer_mac17.80.200.162.110.78.
Hi, Sorry for the very long delay. Did you manage to find solution to your problem?
Hi @philips77,
I hope you're doing well! Unfortunately, we haven't been able to find a solution to the issue yet. Your input would be greatly appreciated, as it could help us move forward.
For me this looks like a design issue on your side. There's nothing that we could do from Android side to keep the address. Perhaps you could send some other data, not MAC? And why, in the first place, are you using MAC for that case?
The core logic is that the device which connects with the application to send the enter DFU command should connect with the bootloader. This is due to the presence of multiple devices, and end-to-end firmware updates are also supported. This is a common logic for firmware updates between the application and device-to-device communication. We have had devices using this logic for many years, and it was working as expected, but we recently discovered this issue.