Attachments (1) Download All
Nordic Case Info
  • Case ID: 247595
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Android DFU library not working for Samsung phones on Android 10

Mxoh

We use both the iOS and Android DFU library to support DFU through our mobile application. Recently we found that Samsung phones running on Android 10 have a problem with DFU both on our app and when using the NFR Toolbox. Strangely it shows DFU disconnected on our app but Gatt error in the NFR Toolbox.

We never had a problem with DFU on iOS before. And after various rounds of testing with different with Android devices we finally narrowed it down to Samsung + Android 10 to cause this DFU failure. On other Android devices that run Android 10 for example Huawei and Xiaomi does not encounter any DFU problems. And Samsung phones on other Android versions do not encounter this DFU problem too. We even had a Samsung phone that was originally running Android 9 and it worked for DFU but after upgrading this same device to Android 10, DFU stopped working. 

I wonder if this is a known issue as more and more Samsung devices on Android 10? And any suggestions on how to troubleshoot and fix? 

  • 0

    We have just discovered the exact same issue in the last 24 hours. I hope there is a fix for this. We have also discovered that secure DFU works for us using an Samsung phone running Android 10 but a legacy DFU does not. We've tested various phones and have also narrowed it down to specifically Samsung phones running Android 10, and specifically legacy DFU.

    Hopefully Bjorn or another Nordic Guru can help. This issue is 100% repeatable in our testing.

  • 0

    Hi Mxoh and Scott, 

    could you capture a on-air trace with the nRF Sniffer Plugin in Wireshark or with a Bluetooth Low Energy protocol analyzer and attach it to the ticket?

    I have seen other customers having issues with Legacy DFU and Android 10 where the nRF52xxx device disconnects either after the DFU start command or the Firmware size is sent by the Android device, see the Message Sequence Chart in the DFU Profile documentation. 

    I am looking in to this as we speak, so if you can provide on-air traces then I can see if you are experiencing the same issue or not. 

    Best regards

    Bjørn 

  • 0 in reply to bjorn-spockeli

    Bjorn,

    I'm not skilled enough to do that, but would the log from nRF Connect help? See attached. It does appear to show the scenario you're describing.

    Fullscreen Log%202020-04-10%2009_46_52.txt Download
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    nRF Connect, 2020-04-10
    Tailwind_00000 (EC:4C:71:F3:53:0C)
    V 09:45:44.766 Connecting to EC:4C:71:F3:53:0C...
    D 09:45:44.766 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
    D 09:45:45.329 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
    I 09:45:45.329 Connected to EC:4C:71:F3:53:0C
    D 09:45:45.353 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
    V 09:45:45.387 Discovering services...
    D 09:45:45.387 gatt.discoverServices()
    I 09:45:45.656 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
    D 09:45:46.153 [Callback] Services discovered with status: 0
    I 09:45:46.153 Services discovered
    V 09:45:46.184 Generic Access (0x1800)
    - Device Name [R W] (0x2A00)
    - Appearance [R] (0x2A01)
    - Peripheral Preferred Connection Parameters [R] (0x2A04)
    Generic Attribute (0x1801)
    - Service Changed [I] (0x2A05)
    ···Client Characteristic Configuration (0x2902)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Scott--R

    Hi Scott, 

    at 09:46:10.809 I see that the Android 10 device is writing the DFU Start OP code to the DFU control point which will trigger the nRF to reset into the bootloader, see Switching to bootloader/DFU mode. The nRF will then start advertising as DfuTarg and the DFU Library on the Android device should then try to connect to the bootloader. 

    In SDK v11.0.0 the bootloader will increment the address by 1 if the application was not bonded with the central. This is to avoid issues with centrals that cache the GATT table of its peers. If the address was not incremented then the central could still think its connected to the application and use its GATT table when writting and reading characteristics. 

    If the central is bonded with the application,  then the bootloader will  use the same address as in the  application and perform directed advertisment towards the central that triggered the DFU process. The bootloader will then issue a service changed indication so that the central performs a new service discovery after connecting to make sure that the GATT table is updated before any characteristics are read or written to. 

    So in your case I would like to know if the nRF is advertising as DfuTarg after theJump to bootloader sent (Op Code = 1, Upload Mode = 4) is sent and the nRF disconnects. You should be able to use the nRF Connect app to scan even though you have initiated the DFU process. 

    If it is advertising, then which address is it using, the same as the application or the the application address +1 ?

  • 0 in reply to bjorn-spockeli

    Hi Bjorn. I've asked a more knowledgeable person to respond here. This is starting to go above my knowledge level quickly.

1 2 3
Terms of service