Timeout exit from the boot loader

[DX_HK]

I am developing an application that uses NCS2.8.0.

For FW updates, the nRF52833 USB ACM bootloader is enabled.

However, there are some problem.

My device has a battery but no reset button, so the application cannot start unless I reset it with mcumgr.

Since we do not want to unnecessarily expose the bootloader to users, bootloader startup cannot be used at any time.

The bootloader timeout seems to only be effective if the bootloader always starts after a reset.

CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=y
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=2000

Is it possible to only enable the bootloader timeout?

Or can I exit the bootloader by other means (e.g. user switch)?

[Vidar Berg]

Hello,

Please correct me if I'm wrong, but is my understanding correct that you're fine with the bootloader always enter serial recovery mode on startup, but you prefer not to expose any mcumgr commands in the application?

Thanks,

Vidar

[DX_HK]

No, I don't want the bootloader to start during normal boot.

In other words, the bootloader will only start with
bootmode_set(BOOT_MODE_TYPE_BOOTLOADER);

[DX_HK]

Thank you. I have performed a test implementation and it is working properly.

This bootloader timeout feature seems more commonly needed.
This time, I customized the bootloader, but customization by general users is not a good thing.
I think such basic functions should be selectable without modifying the code.

What should we do if multiple people are developing this custom bootloader?
Specifically, there are several engineers in the company who develop using Zephyr, and the bootloader should be common, so this change should be synchronized via git (github).

For example, would it be possible for us to create a fork of NCS and use that instead of the nordic repository?

[Vidar Berg]

Possible options that come to mind:

1. Create a patch file that you apply that you and your coworkers can apply to the SDK during installation

2. Submit a PR to propose your change at https://github.com/mcu-tools/mcuboot 

3. Create a workspace application that includes a fork of the https://github.com/nrfconnect/sdk-mcuboot repository (see Forking a repository of the nRF Connect SDK). 

[nick_bike]

I'd like to +1 this functionality. We have a product with a permanently installed battery. We want mcuboot serial recovery via USB (ACM) when a button is pushed;but, if a user accidentally presses that button on turn on, mcuboot sits there forever waiting for a command. We're up for creative ideas, such as having a global watchdog of maybe 2 minutes, and not feeding the watchdog from mcuboot - which in our understanding would force a reboot and allow up to 2 minutes for a device recovery, which seems sufficient.

Thanks!

[Vidar Berg]

Looking at this commit it looks like it should be possible already to have it timeout automatically: https://github.com/mcu-tools/mcuboot/pull/2277/commits/ab2d7bc44f3b658f870f2a93bef58e6f59bf6872 if you use CONFIG_BOOT_USB_DFU_GPIO together with CONFIG_BOOT_USB_DFU_WAIT. Are you using CONFIG_BOOT_USB_DFU_GPIO as your entry method? 

[nick_bike]

I have reviewed the main.c code and it appears (interestingly) that CONFIG_BOOT_USB_DFU_WAIT is being used in two ways.

1. If CONFIG_BOOT_USB_DFU_GPIO=n

Pin DFU is not used - so, enters DFU mode for the duration of CONFIG_BOOT_USB_DFU_WAIT_DELAY_MS.

2. If CONFIG_BOOT_USB_DFU_GPIO=y along with CONFIG_BOOT_USB_DFU_WAIT=y

mcuboot does NOT enter DFU automatically. The CONFIG_BOOT_USB_DFU_GPIO rule changes the operation of CONFIG_BOOT_USB_DFU_WAIT. DFU is only entered if the DFU pin is active. DFU times out after CONFIG_BOOT_USB_DFU_WAIT_DELAY_MS.

My observation is that DFU boot never exits if DFU has been started in any way, including error bytes being written into the serial RX. I will look ito enabling the watchdog in mcuboot.

[Vidar Berg]

Thank you for the update. I will report this internally for review and to (re)consider what the expected behavior should be. I think it makes sense to fall back to the application, or at least provide the option to do so, even in cases where serial recovery mode has been entered but then stopped (for example with an inactivity timer). Allowing the WD to be started from the bootloader could also be something to consider.

EDIT: I see someone already contributed a solution for setting up the WD in the bootloader here: https://github.com/mcu-tools/mcuboot/pull/2566/commits 

[nick_bike]

The scenario is where the device is in the hands of an end customer and they have limited ability to troubleshoot or do anything technical. When enough devices are manufactured, all possible error states do occur.

If the end customer has managed to get the device into a dead-end state (e.g. reset while holding the recovery button, with a USB plugged in, which has been observed to half-trigger the DFU.) it needs to recover in the most sensible way.

I think being able to enable the watchdog from mcuboot Kconfig flags (and set the timeout) is the most sensible approach that solves requirements for a number of different cases, and also being able to choose whether mcuboot feeds the watchdog, or not. This would allow the device to reset if mcuboot ended up waiting for DFU bytes forever. It also protects against other unforseen future niche bugs with mcuboot.

EDIT: Noted that a WD update has been created. We'll integrate this once it reaches the nrf SDK.

[Vidar Berg]

I agree with your points. In case you didn't see it, I updated my previous about WDT setup in bootloader already being supported in upstream mcuboot which should be included in our next SDK release. 

[Vidar Berg]

We added a new timeout config here: https://github.com/nrfconnect/sdk-mcuboot/pull/761