MCUBoot does not load application when using CONFIG_BOOT_SERIAL_WAIT_FOR_DFU

Greetings,

I have worked with the MCUBoot and its Serial Recovery feature with success and recently tried to enable the CONFIG_BOOT_SERIAL_WAIT_FOR_DFU option ( as well as the 

CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=5000 option ) with no success as the application is never loaded and the device remains in bootloader mode.
This feature is necessary for us, as our custom board does not have the buttons to enter bootloader mode the typical way using the button & reset.
I am using the nRF52840DK and the sample \v2.1.0\bootloader\mcuboot\samples\zephyr\hello-world .
I have also looked at the proposed solutions in the tickets:
I have also disabled the Mass Storage Device on my nRF52840DK & disabled the logging (RTT).
From what I gather most suggestions are to migrate/update to newer versions of the SDK ( my current version is v2.1.0 ) as it is claimed ( in two of the tickets above ) that there was an issue with this feature which was resolved for newer versions of the SDK. 
Questions: 
1. Could you please confirm the claim that to work with the CONFIG_BOOT_SERIAL_WAIT_FOR_DFU option properly, the SDK has to be updated to a more recent version ( my current version is 2.1.0 ) ?
2. Is there an alternative solution to make this feature work in my existing SDK version (v2.1.0) ?
Thank you and I look forward to hearing from you!
Best regards,
Stavros
Parents Reply Children
  • Hello Amanda H.,

    Unfortunately, I have gone through this sample in detail, and the only thing that this sample has that my application does not are the two lines I added:

    # Enable wait for DFU functionality
    CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=y
    CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=5000

    Apart from including the bootloader the main application it is totally bare and the mcuboot.conf overlay for the bootloader has a few basic options enabled along with the two already mentioned that have to do with the wait for DFU functionality, it is extremely simple. So one would expect enabling the two options mentioned above to work but the device remains in bootloader mode forever even when no commands are sent ( or the serial communications are physically disconnected ). 

    Could you please confirm that this sample builds and works correctly on the nRF52840DK for NCS v2.1.0? I have not been successful in building it as is. It would be extremely helpful to have a mitigation action for this, even if that ultimately is that I have to migrate to a newer version of NCS. But I would like some confirmation that nothing else is possible before I move on to something very time-consuming. I also would like confirmation that a migration to a newer version of NCS would solve this issue.

    Thank you and I look forward to hearing from you.

    Best regards,

    Stavros

  • Hi, 

    I have tested the sample can work with NCS v2.1.0, but it needs to modify mcuboot/boot/zephyr/Kconfig.serial_recovery as this line https://github.com/nrfconnect/sdk-mcuboot/blob/main/boot/zephyr/Kconfig.serial_recovery#L153C2-L153C52 

    -Amanda H.

  • Hello Amanda,

    I have successfully run the sample with the modification you mentioned! Thanks a lot! It also works as expected when flashed to the nRF52840DK, it exits bootloader mode after the designated wait time and enters the application.

    Unfortunately, the device (nRF52840DK) seems to still stay in bootloader mode and does not start the application when the CONFIG_BOOT_SERIAL_CDC_ACM is disabled I also tried enabling the CONFIG_BOOT_SERIAL_UART option but it also has the same unexpected behavior and the application never starts (it stays forever in bootloader mode).

    Does the CONFIG_BOOT_SERIAL_WAIT_FOR_DFU feature not work without the CONFIG_BOOT_SERIAL_CDC_ACM with the simple serial UART (non-USB)? Is there some other line in the bootloader that needs to be modified or something similar?

    Thank you for your support and I look forward to hearing from you!

    Best regards,

    Stavros

  • Hi Amanda,

    So I will need to migrate to a version higher than v2.2.0 to solve this issue, if I understand correctly, there is no other alternative. Is that correct?

Related