• State Verified Answer
  • Locked Locked
  • Replies 12 replies
  • Subscribers 74 subscribers
  • Views 4186 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 288799
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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)
  • 0 in reply to dev_giraffe

    Hi,

    I got a reply from the apps team:

    1. Q: When testing according to this DFU guide the they first get the message "State: Remote error: Unknown(1)", and get stuck with at the state "UPLOADING" until it times out. I was able to recreate this issue with Android as well, with the addition "Transaction 102 timed out without receiving a response". His logs states that "Length of data to send exceeds MTU", which I've come to understand (from this case) as that the app needs multiple transmissions to perform the update. 

      A       Yesterday we released a new version of the mcu manager library for iOS. As the previous one was maintained by JuulLabs, we had to create a new library, instead of just incrementing the version. The library is located at the same GitHub location, but (if the user is using CocoaPods dependendy manager) change changed name from "McuManager" to "iOSMcuManagerLibrary". Current version is 1.1.0. If they are using SMP, or some other way of including the code, this may not be important.

      The Unknown (1) error is sent from the remote device. The meaning depends on the method throwing this error. For example, it may be thrown from: https://github.com/nrfconnect/sdk-zephyr/blob/79b77b4f6130d0db539a6f6655b3e03818ab98a6/subsys/mgmt/mcumgr/lib/cmd/img_mgmt/src/img_mgmt.c#L427 but it depends on the version of their firmware.

      The "Length of data to send exceeds MTU" is always thrown in the library at the beginning, as the manager does not know the MTU of the transport layer, so tries to send super huge packet initially, gets the error with correct MTU and continues with smaller chunks. That is expected and not an error.

      The "Transaction 102 timed out without receiving a response" should not happen. What "Number of mcumgr buffers" are they using? As far as I know one buffer is needed for responses, so for pipelinig we use 3 in the app, assuming the value is set to 4 (default). After setting to 4 in the app you may get some packets getting lost. Try decreasing this value (will make DFU slower). But even with this error, the upload should be successful. The device sometimes does not have a buffer to send a notification, or the notification is lost somewhere. usually, the fw is confirmed by the notification for the following chunk, so the data have been sent correctly.

    2. Q: The customer also states that they get the message "DFU failed: this image has already been flashed (hash value of the prevous image matches current one.)", which also happens with a completely new image. Is it possible this has occured when the images are distinct (different hash values), or is it more likely that they uploaded the same app_uppdate image to the Device Manager for testing?

      A: This can only happen if the new fw has the same hash as the one on the device. Most prob they're trying to send the same fw. This should not fail the upload, but make it actually succeed immediately. Please, update to latest library version and try again.

    3. Q: Under the "Stats"-tab, they see "No status found" both before and after attempting to flash the image. Is this to be expected?

      A:This depends on the fw on the device. Whatever it returns, the app displays. The SMP Server sample from NCS returns number of ticks since boot, as far as I remember. Other samples may just throw error 8 (not supported).

    What I see from this answer is that the issue is not necessarily an mobile app issue, but rather caused the DFU implementation. I will keep investigating to see if I can spot something that might cause this

    Let me know if the answer above clarifies things for you!

    Kind regards,
    Andreas

  • 0 in reply to AHaug
    AHaug said:
    The Unknown (1) error is sent from the remote device. The meaning depends on the method throwing this error.

    I was able to track down the source of MGMT_ERR_EUNKNOWN (which is the error code for a lot of conditions) to img_mgmt.c line 499. It appears to fail at alloc_ctx() within img_mgmt_impl_write_image_data and causes the errstr "img_mgmt_err_str_flash_write_failed".

    On a hunch based off of alloc_ctx()'s function brief, I increased:

    CONFIG_HEAP_MEM_POOL_SIZE=256
    to 
    CONFIG_HEAP_MEM_POOL_SIZE=4096 (the default for a lot of cases)
    ... and the DFU suceeded!
    It looks like CONFIG_HEAP_MEM_POOL_SIZE=0 also works. (in which case it looks like it would use a statically allocated buffer for alloc_ctx())
    Not sure why I had originally set it to 256, I think maybe it had been a configuration I saw in an example while I was trying to get SPI to work. Frustrating, but glad it works now. The error cases could have been a bit more descriptive - I would have thought that the alloc_ctx() failure should return 
    MGMT_ERR_ENOMEM.
Related
Terms of service