Open philips77 opened 5 years ago
I'm only doing one weird thing, at least knowingly. My nRF52 firmware application always erases the device's bond information when it starts up. I don't think the bond-erasing weirdness should be causing my CRC error because I am not bonding anything. Besides, a DFU kicks the nRF52 into bootloader mode, which shouldn't be running my application anyway. It is possible there is an interaction I am overlooking.
Erasing bonding should not matter.
I see that the Init Packet write fails. The device reports 3 times that it received 0 bytes. It seems that shorter packets were sent correctly, prior to that. You may try disabling MTU request (import the lib as module, not from jcenter, and comment out MTU request), or adding some delays around sending the Init Packet (also requires importing the lib as a module). I don't know why would the target fail to save the data. It may be related to the upload speed, the LineagaOS may handle MTUs incorrectly, etc. I can't tell without a sniffer trace.
@josephtoles
Disabling MTU request does not appear to have any effect. I disabled MTU by importing the library from source and then writing this.mtu = 0
in the method public DfuServiceInitiator setMtu(final int mtu)
.
I don't know where in the DFULibrary project to best put delays. I will update this Issue when I have a sniffer trace.
Hi, did you manage to solve the issue?
@philips77 any news about this issue? we're having the same problem :(
Try setting the delay for each object using https://github.com/NordicSemiconductor/Android-DFU-Library/blob/07bdaa50cfc5786790bf1ac589b14931de65d099/dfu/src/main/java/no/nordicsemi/android/dfu/DfuServiceInitiator.java#L213. Value 300ms should work.
@philips77 Thank you very much, I'll try right away!
Any news about this issue? We're having the same problem.
Could you paste your logs, please?
Ordinarily I wouldn't bother you, but I've been working full-time for a week to get Android DFU into my app. The new error is a CRC mismatch. In the
DfuProgressListener
, it's expressed as a 4109 error followed by a 4096 error.I can open up a separate Issue thread for this CRC mismatch if you'd prefer.Setup
The setup begins with the nRF52 unbonded, unconnected and advertising. The phone does not have any connections saved. Then I perform a BLE scan programmatically in my Android app's Java code. My programmatic BLE scan detects the advertising nRF52 chip. Then I call
DfuServiceInitiator.start(...)
. The Android-DFU-Library updates firmware just fine on the stock Verizon Samsung phone. It fails on the LineageOS Moto X Pure phone.Samsung Galaxy S5 with Verizon's stock ROM
The Samsung Galaxy S5 running Verizon's version of Samsung's stock ROM (Android 6.0.1) updates firmware just fine.
DfuProgressListener
callbacksDfuImpl
logsMoto X running LineageOS
I'm running exactly the same mobile app on the Moto X. I've made sure to grant the runtime location in the phone's settings. I do not get a
java.lang.SecurityException
. However, when I perform a scan, the DFU fails. My mobile application does not request the Location Permission outside ofAndroidManifest.xml
, nor does my app check for it.DfuProgressListener
callbacksDfuImpl
logsConclusion
As you can see, the Checksum succeeds on the Verizon Samsung phone but fails on the LineageOS Moto X phone. Do you know why this might be? Both phones are running exactly the same Android mobile app. They are uploading the same zip packet to the same nRF52. I haven't done anything unusual to configure either of their Bluetooth systems.
Originally posted by @josephtoles in https://github.com/NordicSemiconductor/Android-DFU-Library/issues/127#issuecomment-429742633