Closed archie94 closed 6 months ago
You may try the following:
You may try both methods using the nRF DFU app on Google Play and going to Settings. There may be several reasons why a device would fail like that.
You may try the following:
- Disabling MTU request
- Enabling PRN=1
You may try both methods using the nRF DFU app on Google Play and going to Settings. There may be several reasons why a device would fail like that.
Could you explain more? Because I got stuck in the same situation.
Some devices, for example Samsung Tab A8, have an issue with the DLE (Data Length Extension, maximum size of a packet that they can send in a single packet). During connection negotiation they claim to support only 27 bytes, while later they send more, which gets ignored by the peer. To workaround that it's possible to disable MTU request, which will default to 27 bytes.
If you're using nRF DFU app:
When you implement DFU in your app: https://github.com/NordicSemiconductor/Android-DFU-Library/blob/ee04574dcc438bf067505327eebb37018ee908b8/lib/dfu/src/main/java/no/nordicsemi/android/dfu/DfuServiceInitiator.java#L426-L435
[!Note] With MTU request disabled DFU will be significantly slower.
PRNs, or Packet Receipt Notifications are used to synchronize transmitter with the receiver. Every N packets the transmitter would pause upload and wait for a notification from the receiver with a current offset and CRC. PRNs make sure the transmitter doesn't send data faster than they can be stored on the device.
When you implement DFU in the app: https://github.com/NordicSemiconductor/Android-DFU-Library/blob/ee04574dcc438bf067505327eebb37018ee908b8/lib/dfu/src/main/java/no/nordicsemi/android/dfu/DfuServiceInitiator.java#L221-L252
[!Note] Just like with MTU, the lower PRNs, the more time sending them takes, so the DFU process gets slower.
Thank you so much for these detailed explanation. I am going to try these out and let you know.
Thank you so much for these detailed explanation. I am going to try these out and let you know.
Thank you but form my side I should say It was a bug in the library I used. I could not test it without PRNs because I don't have enough memory to buffer the input data, so I should've tested it with PRN = 1. When I received a packet, I did not send CRC response notification. It was my problem. Thanks again for your attention.
Version
2.4.1 (Latest)
Ask the question
Do you know why this device is not able to update the firmware version?
Logs attached.
Relevant log output