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

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:

#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

Parents Reply Children
No Data
Related