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.

[AHaug]

Allright, then I'll have one more potential solutions to this issue before digging deeper. 

Simon referred me to this other similar issue where an iOS user were experiencing the same data-length issue. Here the conclusion was that this is to be expected and that the message only ment that the iOS DFU library will send the data in more than one transmission, and will not cause any problems for you. 

If this is correct, then it should be possible to check the difference in build timestamps according to the testing step in the guide to verify if the DFU went through and the new build is running

Could you try to perform the testing steps for DFU over Bluetooth and compare the two serial terminal outputs to see if it is the first or second build that boots up after pressing test and confirm? 

AHaug said:

Fix

Post note: This seems to be an issue when running the guide with NCS v1.9.1 and were not present in v1.8.0

Kind regards,
Andreas

[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