MCUBoot hangs when using CONFIG_BOOT_SERIAL_WAIT_FOR_DFU

[StephenApprox]

The BOOT_SERIAL_WAIT_FOR_DFU feature is meant to wait a number of milliseconds (500 by default) for a message via serial comms. If it doesn't receive a message it continues to boot as normal. The problem is that it waits forever, and never boots as normal.

It looks the cause is within boot_serial_read_console() in bootloader/mcuboot/boot/boot_serial/src/boot_serial.c.

This function calls k_cpu_idle() which never returns as no interrupts happen.

Have I missed something? Or does this feature not work!

Thanks

[Marte Myrvold]

Hi,

Is this on a custom board or DK? If it is custom you must make sure to set the clock config in MCUboot as well, in addition to in the board file. Child images do not inherit this configuration. so you must explicitly set it in the child image's configuration (for example child_image/mcuboot.conf).

Best regards,

Marte

[StephenApprox]

Thanks for the reply. I've tried it on a dev board as well, PCA10040 (as I'm using nRF52832), and the same happens.

To clarify, the bootloader works fine without the wait_for_dfu feature enabled. And when it is enabled, I can enable RTT logging in MCUBoot and see that it reaches the k_cpu_idle() call. After that it remains inside k_cpu_idle() until a character is received on the serial port. But if no character is received it has no way for execution to continue.

Do you think k_cpu_idle() should return without an interrupt occurring? And this is related to clock configuration?

Thanks again for looking into this.

[Marte Myrvold]

Hi,

I have seen issues with MCUboot on custom boards previously due to missing clock configuration, but since you can reproduce it with a DK this should not be the cause of the issue.

A colleague of mine has previously seen an issue with logging when using CONFIG_BOOT_SERIAL_WAIT_FOR_DFU. Without it logging works fine in both the bootloader and application, but with this enabled he gets logging from only one of them, most likely due to a race condition. Your issue might be something similar or another race condition.

I have a couple of things you can try. The first is to debug the application to check whether the issue is the logging or that the application does not boot. 

The second is to try with another example. You can for example use the Hello World sample and add the MCUboot functionality there, or you can use this USB CDC wait for DFU example made by a colleague of mine: mcuboot_serial_recovery_cdc_acm_wait.

Best regards,

Marte