Device becomes un-updatable forever if wrong (s0/s1) update image is transferred in a two-stage bootloader setup

[Adam Varga]

Hello people!

I'm experimenting with the two-stage bootloader (NSIB+mcuboot) for OTA updates, and according to my understanding, I need to alternate between the _s0_image_update.bin, and the _s1_image_update.bin image versions according to which image slot is currently not used, every time I want to update the mcuboot.

#Question 1: Is this really the expected method for updating the mcuboot? It seems really impractical to keep track or figure out the current active mcuboot slot, while our devices are in the users' hands.

-

Now, let's assume that's the necessary method, but something goes wrong, and the wrong image version gets transferred and then flagged on a device. My tests showed that this scenario bricks the device, as the image remains "pending" forever, blocking any corrective further updates. I'm using the nRF52840-DK with the simplest blinky example, then I enabled mcuboot and NSIB in the settings. I see the same results with NCS 2.3.0 and 2.4.0 as well. Please see the attached picture of the steps I took:

Further notes:

• If I upload the mcuboot s1 version first, then alternate (or upload a new app version), everything works as expected (so I'd assume my settings are somewhat correct)
• I've seen and tried the examples from the Hellesvik-repository
• These people are also experiencing similar issues, but I couldn't get clear answers to my questions :
  • OTA DFU Stuck in pending
  • McuBoot doesn't switch to pending image
  • How to erase flash area s0 and s1 when using NSIB?

#Question 2: So I transfer the wrong mcuboot image (s0/s1), is the expected behavior that the device gets un-updateable (essentially bricked from an OTA standpoint)?

#Question 3: If this is normal behavior (which I doubt), then what's the recommendation to make this procedure robust and suitable for a production environment?

Thanks in advance, 
Adam

[Menon]

Hello,

Letting you know I have been assigned to this case and I have started looking into this.

I will get back to you soon.

Kind Regards,

Abhijith

[Menon]

Hello,

Sorry for the long response time taking here. It's summer vacation here in Norway and we are very thinly staffed. Sorry for any inconvenience cause because of this.

You can expect a proper response by the end of this week.

Kind Regards,

Abhijith

[Menon]

Hello,

Thank you for your patience and sorry for the time I took here.

The process of updating MCUboot is similar to application update. Choose the update.bin (for testing_not for production) file and then send to the target. But the tricky part is to choose which file. Basically there will be two mcuboot, identical in code, but one is loacted at S0 and one is moved to S1.

 

Next step is to choose which file to update. It depends on which MCUBoot is active. If S1 is active,  you need to update S0 (use signed_by_mcuboot_and_b0_s0_image_update.bin)  and if S0 is active you update S1 (use signed_by_mcuboot_and_b0_s1_image_update.bin) .The NSIB will run the MCUboot in S0 or S1 based on which slot has a valid bootloader with the higher monotonic version number. There is no swap. You can see the current active slot from the log or you can implement this in the application using the function fota_download_s0_active_get() .

#Question 2: So I transfer the wrong mcuboot image (s0/s1), is the expected behavior that the device gets un-updateable (essentially bricked from an OTA standpoint)?

AFAIK, updating the wrong image will the break the DFU process. But I don't think it will put the device in a bricked state.

Question 3: If this is normal behavior (which I doubt), then what's the recommendation to make this procedure robust and suitable for a production environment?

If you are looking for an app(mobile/PC) that can read the current active partition and send it to the DFU master, then I am not sure about this.

Kind Regards,

Abhijith

[Adam Varga]

Dear Abhijith,

Thanks for your answer, and allow me to have some follow-up questions/comments.

1. Why is update.bin not for production (assuming a new signing key is properly generated)? What is for production then?
   
   

2. Getting the currently active MCUboot slot with fota_download_s0_active_get() then deciding which new image to send before doing an update would work, thanks for the suggestion! (Although I find it weird that I need to use a networking library on a chip without internet access just to decide which bootloader slot is active.)
   
   

3. Is there a possibility to verify the signature of the new image (that has been transferred to the right slot, but has not been activated yet) from the application itself without a reboot?
   
   

4. It would be my assumption as well that updating the wrong image will not brick the device, only break the DFU process, but that is still my observation. Could you somehow repeat my steps and verify that it works for you? Then maybe we could compare our settings or something.

Thanks, 
Adam

[Menon]

Hello,

Sorry I was away for the last few days.

I recommend you read the section on building FOTA images, which will give you an idea about the build files. See the difference between app_update.bin, dfu_application.zip, and dfu_mcuboot.zip.

Adam Varga said:

It would be my assumption as well that updating the wrong image will not brick the device, only break the DFU process, but that is still my observation. Could you somehow repeat my steps and verify that it works for you? Then maybe we could compare our settings or something.

Sure, I will try to test this here and get back to you.

Kind Regards,

Abhijith