nRF Connect SDK DFU over BLE fails with bad State: Remote error: Unknown(1)?

[dev_giraffe]

I am having trouble setting up DFU over BLE in nRF Connect SDK. I am using NCS 1.9.1.

I have followed these instructions with my own project on both the nrf52840 devkit and a custom board: https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/software/posts/ncs-dfu

Side note: The DFU UUID in this guide did not work for me: I used the UUID that is shown in the iOS nRF Connect Device Manager App when no devices are found:

BT_UUID_128_ENCODE(0x8d53dc1d, 0x1db7, 0x4cd3, 0x868b, 0x8a527460aa84)

With this UUID, I was able to connect with the device manager. However, when I start the image upgrade with "erase application settings" enabled and mode "test and confirm", I get this message: "State: Remote error: Unknown(1)". If I try again after that, the state says "UPLOADING..." until it times out. (restarting the app recreates the unknown(1) error).

When I try uploading the same firmware image to the same device via the nRF Connect for iOS app, I get more details. The log looks good until I get a message "Length of data to send exceeds MTU". This seems straightforward, but I am failing to get it resolved.

Is 252 (as stated in the above guide) the correct MTU length? If not, how do I change it? I've tried messing around with several of the CONFIG_ values, but it doesn't appear to update because I see in the nRF Connect iOS app the MTU is the default 23. 

Any help appreciated, thank you!

EDIT:

for anyone else who comes across this problem:

- "Length of data to send exceeds MTU" is an expected message and doesn't indicate a problem

- The issue ended up being that I had set CONFIG_HEAP_MEM_POOL_SIZE=256, which is too small for the DFU to allocate the buffer needed to write to flash. OK values I tested are 4096 and 0(instead of allocating from heap, a static buffer is used). Optimal size is probably sizeof(struct flash_img_context)

[dev_giraffe]

I stripped all other functionality out of my code and applied the DFU setup to the button example, the project zip file is attached. This produces the same problem on my end. I will attempt the DFU from an android phone tomorrow, please let me know if you find anything that may be wrong with my setup.

button_dfu_example.zip

[AHaug]

Hi,

dev_giraffe said:

I stripped all other functionality out of my code and applied the DFU setup to the button example, the project zip file is attached.

Great! Thanks for supplying the project zip. I will set up at similar test with this project to see if I am able to reproduce the error.

dev_giraffe said:

At first I thought I was just receiving this error because I was trying to flash the same image over and over again and it was maybe a caching issue within the app, but I also receive this error when I'm trying to flash a completely new image.

I must admit that the thought struck me. But if you get the same issue with a new image it should not be the case. Just to confirm: The file you're uploading to the device manager to perform the DFU is the app_update.bin file located in build->zephyr, right?

dev_giraffe said:

In the Device Manager app, under Image>Advanced I read the current image on the device as: 

It seems like the iOS apps app is somewhat different than the Android app (which is not really a surprise), so I will try to find someone who can perform the same tests with iOS. The I can only see the file name, size and Hash under the advanced tab here. The file hashes between two different builds are distinct as shown in the image 

dev_giraffe said:

Are these values normal?

I will ask the iOS app developers if they know the answer to this. 

I'll come back with an answer with my progress as soon as I can verify with the developers, and with results from reproducing the issue with your project, none later than by the end of this working day

Kind regards,
Andreas

[dev_giraffe]

AHaug said:

Just to confirm: The file you're uploading to the device manager to perform the DFU is the app_update.bin file located in build->zephyr, right?

Correct

Thank you Andreas, I'll continue to look into it on my end

[AHaug]

Hi,

Updating with the results from today

I was able to reproduce your errors, but sadly I have found no fix so far. The symptoms are that the update starts and is stuck at state "uploading" until time out where I get the state "Transaction 102 timed out without receiving a response". This leads me to believe (but not necessarily verify) that the DFU implementation is lacking anything.

Did you have any more luck on your end?

If you follow the guide to the letter, does the DFU work for you with the modified peripheral_lbs sample?

Also, another question regarding precisely how you performed the update steps just to exclude any mishaps: Is it correct that you performed the following steps when testing?
1) Build and flash the application to the DK/Custom board
2) Build the application again and add the app_update.bin binary from build/zephyr to the device with Device Manager
3) Selecting the app_uppdate.bin on the image tab
4) Pressing  start -> Test and confirm

I have asked the app team for more information regarding the rest of the questions as well as for input on details regarding the fault messages.

Kind regards,
Andreas

[dev_giraffe]

I tried the DFU using the zip'd project I uploaded and ran into the same error. 

I followed the guide to the letter and succeeded in DFU. What's more, I didn't get the error message "DFU failed: this image has already been flashed (hash value of the previous image matches current one.)". I am trying to figure out what the difference is between my code and the peripheral LBS but struggling to find something that makes my app's DFU work.

I am beginning to suspect that the app refuses to send the DFU because it believes that the hashes are identical, but I can't figure out why the app thinks so.