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)

[AHaug]

Hi,

I've tried the guide myself and I believe I was able to recreate the issue you're experiencing (albeit with an Android device and app). I am adding a description of my issue so you may compare it to your case, aswell as my fix to this issue: 

Description:

After building and flashing with erase setting, connecting with nRF Connect, adding the update image to the and pressing "test and confirm", the app starts to download the image, before the DK crashes and resets before it connects again and repeats the motion until it times out. Let me know if I've understood correct w.r to this being similar to your experience.

Fix

Increase CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE in proj.conf from 4096 to 8192 "CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192"

This should allow you to download and update the image without the DK crashing.

Let me know if this fixes your issue, or if you've tried this already.

Kind regards, 
Andreas

[dev_giraffe]

Thank you for checking it out, however I'm not getting the same symptoms as you. My device does not crash and reset, in fact it is completely functional and recoverable after every attempt I've tried so far. I did increase the workq stack size but it had no effect, in the iOS nRF Connect app I still get the "Length of data to send exceeds MTU" even though on the device's advertisement page the MTU is set at 252 bytes.

[dev_giraffe]

That does look like a similar issue, but for me the DFU never completes, progress bar never fills up, the device doesn't reset and the build timestamp on the device does not update with the new image. My nRF Connect iOS app shows the exact same error log as the issue you linked, but stops at the MTU message.

If the MTU message isn't a concern, maybe there is something else that is causing this issue. 

[dev_giraffe]

Ok, now I have noticed the on my first attempt at flashing the image via DFU, I get the message "DFU failed: this image has already been flashed (hash value of the previous image matches current one.)". 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 checked that the binaries that I'm testing are distinct. Is this normal?

In the Device Manager app, under Image>Advanced I read the current image on the device as: 
Split status: 0
Image: 0
- Slot: 0
- Version: 0.0.0
- Hash: XXXXXXXX(long string of hex, different from what is shown when I select an image to flash)
- Flags: Bootable, Confirmed, Active

Under stats I get "No status found." both before and after attempting to flash an image. 

Are these values normal? It seems pretty empty to me 

[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