• State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 71 subscribers
  • Views 3556 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 286650
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

OTA DFU Stuck in pending

qualry

I have adapted and incorporated the NCS OTA DFU sample into my project. Initially, FOTA updates have been working. Now, after pushing an update, the image is stuck pending in slot=1 (see mcumgr output below). It does not swap to slot=0 after a reset. Additionally, I can't erase or overwrite this image from slot=1. I get various errors like "Mcu Mgr Error: BAD_STATE (6)" or "Mcu Mgr Error: NO_MEMORY (2)".

This device is already deployed so programming pins are inaccessible; remote management is the only way I can possibly recover this.

Lastly, and I'm not sure if this matters, I wanted to use the LittleFS but it was conflicting with NVS so I made this change the nrf repo:
devzone.nordicsemi.com/.../308671

Is there any I can complete this update or cancel it and start a new one?

sudo mcumgr --conntype ble <connection string> image list

Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: 8cc09b4293faaac3c0d613aaadbeab0aefc4fd87aa85ecc3ad29ac4edbfc3e41
 image=0 slot=1
    version: 0.0.0
    bootable: true
    flags: pending
    hash: 20e3bbee692b24aeb6bdb9cb5cf3fbb8ccc9929ce5cf58cebfc5f2ddf3c771cc
Split status: N/A (0)

BT40F (nRF5340)
git describe in sdk-nrf: v1.8.0-97-gb57588840
git describe in sdk-zephyr: v2.7.0-ncs1-25-g2dca349769

  • 0 in reply to qualry

    @TJ Stone: Thanks for the information. It's very useful. I do agree that there should be a away to fall back if the image couldn't be swapped. 

    @Qualry: Could you explain what you got with the nRF5340dk ? From what I can see in the log the Permanent swap was successful ? 

    From the partition files it seems that you added littlefs to the application and the size of the slots were reduced, but as far as I know this shouldn't be a problem ? 
    TJ was mentioned about the issue when the size of the secondary slot is actually bigger than primary slot causing it not possible to swap , but I guess it's not the case in your device  ? 

  • 0 in reply to Hung Bui

    I have re-ran this steps to cause this issue and saved image list outputs after each step along the way.

    First I upload the image (8cc09b) that introduces the littlefs. When I test the image and restart the device the image is swapped into the the first slot but the original image (c49DD8) doesn't show up in the second slot. Additionally, attempting to confirm 8cc09b doesn't actually do anything. It simply reverts back to the second slot on reset. At this point (step #6) I confirm the image without testing it first. After this the uploaded image remains in slot 1 after resetting.

  • +1 in reply to qualry

    Hi Qualry, 

    There must be something wrong when the littlefs is introduced. If you test doing MCUBoot without littlefs added do you see the same problem ? 

    It's a little bit unclear to me at step 07. Seems like after step 7 the image (8cc09b) is switched to slot 0 ? 

    On step 8 (20e3b) is updated but not able to switch to slot 0 ?  Is there any different in the partition map between the (20e3b) and (8cc09b) ? 

    Update: 

    I have checked a little bit with our team and it seems that indeed the littlefs partition is causing an issue. The reason is that MCUBoot store metadata (image trailer) at the end of the image flash area. In this case you have the littlefs area occupy from 0xf8000 0xfe000, covering the end address of slot 1 (of the old set up  0xfc000) . 
    My suggestion is try to limit the size of the littlefs to address 0xf8000 to 0xfb000 or move it down in the flash if the size can not be changed. 

    But anyway you may need to update MCUBoot because the image map on MCUBoot is fixed and it may cause you a trouble when you continue to do DFU in the future. 
    So it's very important that you match the partition map on the new image to the old image. 

  • 0 in reply to Hung Bui

    > It's a little bit unclear to me at step 07. Seems like after step 7 the image (8cc09b) is switched to slot 0 ?

    Yes. However typically when you confirm an image and reset the device the images in slot 0 and slot 1 switch places. Yet what is happening here is that (8cc09b) swaps into slot 0 and (c49DD8) is nowhere to be seen.

    > Is there any different in the partition map between the (20e3b) and (8cc09b) ? 

    Yes. The different partitions.yml file are as in this comment: https://devzone.nordicsemi.com/f/nordic-q-a/86332/ota-dfu-stuck-in-pending/361077#361077


    > So it's very important that you match the partition map on the new image to the old image. 

    This looks like the solution moving forward. Unfortunately, it looks like my current devices are bricked.

  • 0 in reply to qualry

    Hi Qualry, 

    qualry said:
    Yes. However typically when you confirm an image and reset the device the images in slot 0 and slot 1 switch places. Yet what is happening here is that (8cc09b) swaps into slot 0 and (c49DD8) is nowhere to be seen.

    I think this reflected correctly the issue that the littlefs partition is covering the slot 1 image trailer. This is why you don't see the old image any more. 
    But I haven't seen the issue DFU Stuck in pending in your test. Could you clarify ? 

    I believe there should be a workaround if you place the littlefs location correctly, as long as it doesn't mess up with the image trailer. However in the long run it may not be the best option to use this workaround. 

Related