Android DFU library

[yangamin]

答复 答复 转发 Android DFU library.msg

Hi!We used a 52832 to make a bracelet. Now some apps on Huawei phones can't be remotely upgraded by the ring. We have verified that Nordic's official Android DFU library throws a bug in the firmware upgrade. Therefore, during the upgrade process, whether the mobile phone is sent incompletely or the wristband is not completely received, our APP cannot be detected here.Before using nRF Sniffer to capture packets, there is no data during the upgrade process.Before using nRF Sniffer to capture packets, there is no data during the upgrade process.Above have our software testing environment, please check.
According to the log of nova 2s combined with the DFU library code analysis, the following is the error when the data is verified.
The error is as follows:
Sending Calculate Checksum command (Op Code = 3)
08-27 11:38:24.029 1637 1802 W bt_btif : HAL bt_gatt_callbacks->client->notify_cb
08-27 11:38:24.030 7911 8203 I DfuImpl : Checksum received (Offset = 256, CRC = 975ECD47)
08-27 11:38:24.030 7911 8203 W DfuImpl : 3840 bytes were lost!
08-27 11:38:24.031 7911 8203 I DfuImpl : CRC does not match! Expected 491D1F48 but found 975ECD47. Retrying...(3/3)
The program sends the data three times and reports the same error.
The judgment is that the receiving firmware data is incomplete and the upgrade fails.

Is DFU lib usage problem or data compatibility issue? Is there a solution?
Thank you for your reply!

[Nathan]

I just ran into this issue myself, using SDK 15.3.0 and a Pixel 3a Android phone using the latest version of the nRF Connect app. After pressing the DFU button and selecting the file, the app would push the board into bootloader and the upgrade would start, but I'd get the "bytes were lost" and "CRC does not match" messages in the log and it would quickly fail. The phone's DFU retry procedure would start, but the board would disconnect and refuse to advertise until it times back out to the originally loaded application. 

I noticed that if I allowed the app to push the board into bootloader and then immediately closed and restarted the phone app, when I subsequently reconnected to the board and hit the DFU button again, the procedure would succeed this time. I think there's some kind of timing issue where the bootloader is too busy doing something when it first starts up and it winds up dropping incoming data if the DFU procedure starts too quickly. 

For now I've also discovered a temporary workaround where I limit the maximum MTU size in the bootloader via NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 63, instead of the default 247. If I do that, the whole DFU process works perfectly without requiring me to reset the phone app in the middle of the procedure. 

I can get full traces of everything once I have the the time (wireshark OTA capture, nRF logger output, video recording of the phone side plus logs), but I'm a little too busy at the moment. 

Edit: Scratch the workaround, I just got lucky a couple times. Still trying to find a way to solve. 

[Hung Bui]

@Nathan: This is an old case, please create a new case and describe your issue, you can give a link to this case if needed.