dfu update failed (device disconnected) #376
Assignees
Labels
Comments
Closed
|
Hello,
I wonder why. In Legacy DFU, unless you use Are you sending the same fw using 2.3.0 and 1.11.0? Could you share log from 1.11.0? |
|
Hello, yes same FW. I used the same FW and same phone Redmi 9C.
Yes same fw, I bumped on my project the DFU library from 1.11.0 to 1.12.0 and it work well too How I initialize the DfuServiceInitiator // Kick off DFU
final DfuServiceInitiator starter = new DfuServiceInitiator(bleAddress)
.setDeviceName(bluetoothManager.getAdapter().getRemoteDevice(bleAddress).getName())
.setForceDfu(true)
.setNumberOfRetries(DFU_NUMBER_OF_RETRIES)
.setPacketsReceiptNotificationsEnabled(true)
.setPacketsReceiptNotificationsValue(PACKETS_RECEIPT_NOTIFICATIONS_VALUE)
.setKeepBond(keepBond);Logs DFU lib 2.3.0 DFU lib 1.12.0 |
|
Did you try disabling MTU request when using 2.3.0? |
|
I disabled the MTU request with 2.3.0 but I got the same behavior. DfuServiceInitiator Logs 2.3.0 |
|
Hmm.. I see that 1.11 spends almost 7 seconds erasing the secondary slot: but 2.3.0 gets a disconnection after just 4: |
|
Still have the issue with some mobiles with the latest app DFU 2.3.1
|
|
This, actually, indeed may be due to the remote not sending any packets while it erases the slot. Have a look at the log I pasted before: The Supervision Timeout was set to 400, which translates to 4 seconds. And exactly after 4 seconds the connection is terminated. If it is possible to modify the fw to request longer connection interval, that would help. Or, we can add a Connection Priority request from Android just before sending the sizes. Starting from Android 8+ Android requests 5 seconds Supervision Timeout, but seems like you need almost 7. I wonder why 1.11 works... |
|
The logs from 1.11 you pasted above also have 4 seconds Supervision Timeout: |
|
Perhaps it's not the Supervision Timeout, after all. |
|
I tried on an other phone (samsung a15) with the latest version (2.5.0) of DFU lib but I still have an issue with the latest one and I notice that with an old version (2.1.0) the update works I tested both versions on the same phone, same application I only changed the used version of the dfu library. DFU Bootloader version:
Device information:
With Android DFU lib 2.5.0 (not working)
With Android DFU lib 2.1.0 (working)
How I initialize the DfuServiceInitiator |
|
Hi, |
|
Hi everyone, P/S: With the same application as above, it works well on Google Pixel, confirmed on multiple Google pixel and all were OK. |
|
Hi, @tudang88 I received a customer message this morning he has a Samsung S23 and the DFU does not work either... @philips77 I tested the 2.9.0, on some phones the DFU work well while on others the update systematically fails. I will dump the logs soon on this thread. |
|
DFU Bootloader version (please complete the following information): How I initialize the DfuServiceInitiator |
|
Hello, line. The Service Change indication should be sent to a bonded peer whenever the attribute table (list of services) changes. I would expect it to be sent after switching to the "bootloader mode" instead. I assume your app is using the services on the device in "app mode" on each connection, so these are the "normal" ones. SC indication should indicate change - that is when jumped to "DFU mode" and again after DFU completed in "app mode". Anyway, the library sends a command to switch to the bootloader mode, the device restarts and phone reconnects. Seems again, that the attribute under this handle number is something else, than the library expects. Perhaps I can describe what a handle numbers are. During service discovery, a client reads list of attributes of the connected peer. Attributes are services, characteristics and descriptors. Each characteristic, characteristic's value, a descriptor and its value gets assigned a 2-byte "handle number". These are later used during GATT communication, when you want to read/write a value to a characteristic. In the Andorid API you say "read soem characteristic value", which Android translates to that handle number. When the list of services changes on the peer, it should notify the client about that fact using Service Change indication. This is especially true for bonded devices, for which the client is free to use cache and never repeat serivce discovery process, unless this indication is received. In your case, seems like the services have changed, but the client (a phone with DFU library) doesn't know about it, so it is using the previous handle numbers. On the DFU target the same handle numbers now point to a different set of attributes, leading to errors. Could you try doing DFU using nRF Connect for Android, or nRF DFU app, both of which are on Play Store? |
|
@philips77
|
|
@philips77 Device is bonded to the phone (Samsung Galaxy A145R/DSN (Android 14)) I tried on my S23 Ultra with the same device and it work nice. DFU app Log 2025-03-12 10_48_16 on Samsung Galaxy A145R DFU app Log 2025-03-12 10_50_00 on Samsung Galaxy A145R nrf connect app Log 2025-03-12 13_56_00 on Samsung Galaxy A145R nrf connect app Log 2025-03-12 13_58_10 on Samsung Galaxy A145R |
|
When you get this versiojn = 20.2, could you read the Version characteristic in nRF Connect using the arrow pointing downm then tap "Refresh services" and read the Version charactersitic again? |
|
After a refresh I read "0.1" on the characteristic 00001534-1212-efde-1523-785feabcd123 DFU Version |
|
Maybe an interesting thing: On nRF connect app after the refresh I tried a DFU, it failed, then I read again the same characteristic (without any refresh) and I got the error message: |
|
Yes, this seems like caching issue. Check why the device doesn't send Service Change indication when you switch to bootloader mode. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
DFU Bootloader version (please complete the following information):
Device information (please complete the following information):
Your question
DFU doesn't work , I get errors:
I notice when my phones are bonded to the nRF device the DFU is working.
DFU library 1.11.0 is working on Redmi 9C with or without bonding.
Logs
On Redmi 9C
on Samsung S20 FE
The text was updated successfully, but these errors were encountered: