DFU OTA suddenly fails on "non secure" bootloaders but works on "secure" bootloaders.

[Lennart Andersson]

Suddenly DFU OTA fails most of the time while trying to update units with code & "not secure" bootloader that has been working for years. The FW upload stops at 2% to 8% but if i restart my phone sometimes it reaches 15% and on happy days I can update the unit after rebooting the phone.

With the same DFU app DFU update works well with another unit with "secure" bootloader.

I am NOT trying to update a unit with "not secure" bootloader with code made for units with "secure bootloader" and vice versa.

What can suddenly be the problem?

Phone: Samsung Galaxy S21 Ultra 5G

Android version: 14

DFU app version: 2.9.0 (build 24123065)

[Vidar Berg]

Hello,

Do you know which SDK the "non-secure" bootloader was based on? It would also be interesting to know if you can reproduce this issue with other phones than the Galaxy s21 if possible. 

You can also view the debug logs in the app by swiping right after the DFU has failed. This may provide us some additional clues.

Best regards,

Vidar

[Lennart Andersson]

Hi Vidar!

I think the bootloader is based on SDK11

I don't get any debug logs if I swipe right after upload fail, Nothing happens.

/Lennart.,

[Vidar Berg]

Hi,

Thanks for confirming the SDK version. 

Lennart Andersson said:

I don't get any debug logs if I swipe right after upload fail, Nothing happens.

Are you using the nRF Connect app on Android? 

[Lennart Andersson]

Yes. Samsung Galaxy S21, Android Version 14. But it seems that all android devices share the same problem.

AS I just wrote it has been confirmed that the Iphone app works.

[Vidar Berg]

Thanks for confirming. I'm not sure why you are unable to retrieve the debug logs from the nRF connect app. Anyway, please install the nRF DFU app and and in the app settings, set the PRN (packet receipt notification) to 1. Then install the nRF Logger app and try the DFU again. The nRF DFU app will generate logs in the nRF Logger app.

[Lennart Andersson]

I have done that, No logs appears in the nRF logger.

But it's confirmed that DFU works on Iphone but not on Android. That should be easy for you to check out.

[Vidar Berg]

I have checked it out and tried to replicate the problem on my end using both nRF Connect 4.29.1 and nRF DFU v2.9.0 on a Samsung A21 running Android 12, but without any luck. While it helps to know that it is not failing on iOS, it does not explain why it is failing on Android in your case. 

What happens when you try to view the log in the nRF DFU app? 

[Lennart Andersson]

I have installed the nRF Logger.

Every time I want to "open it" through nRF Toolbox  i first come to "Google Play" from where I can open it.

The same happens if i press the "Magnifying glass" as you suggested above. And when I have started the nRF Logger it only says "No log sessions found".

For some reason I always get directed to "Google play" to start the nRF log app. 

[Vidar Berg]

Then you can try to view the log from the nRF connect app instead. It would also be good if you could try the nRF DFU app with long ATT MTU disabled as suggested by Aleksander Nowakowski 

[Lennart Andersson]

If you by "long ATT MTU disabled" mean unchecking the box "Request high MTU" i have already tried that but it makes no difference.

After installing nRF connect i suddenly got a log from when I try to DFU update and the update percentage reaches 8%

It looks like this:

nRF Connect, 2025-03-31
Dfu_V2.0 (F5:9A:55:96:A5:6B)
D 12:52:23.101 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
V 12:52:23.220 Connecting to F5:9A:55:96:A5:6B...
D 12:52:23.220 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D 12:52:23.236 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I 12:52:23.236 Connected to F5:9A:55:96:A5:6B
V 12:52:23.254 Discovering services...
D 12:52:23.254 gatt.discoverServices()
I 12:52:23.547 Connection parameters updated (interval: 30.0ms, latency: 0, timeout: 4000ms)
I 12:52:23.797 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
D 12:52:23.938 [Callback] Services discovered with status: 0
I 12:52:23.938 Services discovered
V 12:52:23.945 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)
Device Firmware Update Service (00001530-1212-efde-1523-785feabcd123)
- DFU Packet [WNR] (00001532-1212-efde-1523-785feabcd123)
- DFU Control Point [N W] (00001531-1212-efde-1523-785feabcd123)
   Client Characteristic Configuration (0x2902)
- DFU Version [R] (00001534-1212-efde-1523-785feabcd123)
D 12:52:23.945 gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
I 12:52:24.000 Connection parameters updated (interval: 30.0ms, latency: 0, timeout: 4000ms)
I 12:52:24.540 Connection parameters updated (interval: 30.0ms, latency: 0, timeout: 4000ms)
I 12:52:26.031 Connection parameters updated (interval: 15.0ms, latency: 0, timeout: 5000ms)
D 12:52:31.750 [Callback] Connection state changed with status: 8 and new state: DISCONNECTED (0)
E 12:52:31.751 Error 8 (0x8): GATT CONN TIMEOUT
I 12:52:31.751 Disconnected
D 12:52:31.770 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED

[Vidar Berg]

Yes that is what I meant. Regarding the log, it shows a connection timeout, which could indicate that the app is not sending the disconnect PDU as it is supposed to. This results in the phone having to wait for the supervision timer to expire before it can consider the link lost and attempt to reconnect to the device in bootloader DFU mode. 

Have you tried setting the scan timeout to the max. in the nRF DFU app?