MCUboot should only timeout after hardware reset

Hi there,

I've made MCUboot work, but it always timeouts before loading the application firmware. I only want it to timeout after resetting the SoC via its RESET pin.

I added CONFIG_BOOTLOADER_MCUBOOT=y to my prj.conf, and my mcuboot.conf contains the following:

CONFIG_PINCTRL=y
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000
CONFIG_LOG=y
CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_SERIAL=y
CONFIG_UART_LINE_CTRL=y
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_BOOT_SERIAL_PIN_RESET=y
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=y
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=3000
CONFIG_BOOT_SERIAL_NO_APPLICATION=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_BACKEND_RTT=n

My second issue is that I have to add the `-Dmcuboot_OVERLAY_CONFIG=/home/laci/projects/firmware-uhk/uhk/device/mcuboot.conf` west argument every time I build because the VS Code forgets it:

How can I persist this setting? The "Save Configuration as Preset" option doesn't make a difference.

Thanks in advance!
- Laci

Parents Reply Children
  • Hi Vidar,

    I understand that I should remove CONFIG_BOOT_SERIAL_WAIT_FOR_DFU to avoid the initial timeout, but I still want the bootloader to timeout when the SoC is restarted via hardware reset. How can I achieve it?

    Thank you for looking into the VS Code-related issue. I've checked the referenced project, but I can't build the MCUboot-related part of it, and I'd rather wait for your findings.

  • Hi Laci,

    mlac said:
    I understand that I should remove CONFIG_BOOT_SERIAL_WAIT_FOR_DFU to avoid the initial timeout, but I still want the bootloader to timeout when the SoC is restarted via hardware reset. How can I achieve it?

    My apologies. I was under the impression that the CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT applied to all serial entry methods, but I now realize that this is not the case. However, from looking at the main.c implementation for mcuboot, it seems like you can achieve this by simply replacing boot_serial_enter() with boot_serial_check_start() at this line:

    https://github.com/nrfconnect/sdk-mcuboot/blob/6902abba270c0fbcbe8ee3bb56fe39bc9acc2774/boot/zephyr/main.c#L545 

    mlac said:
    Thank you for looking into the VS Code-related issue. I've checked the referenced project, but I can't build the MCUboot-related part of it, and I'd rather wait for your findings.

    I was able to reproduce the same behavior here and have reported it to our VS Code extension team. While waiting for this to be fixed, please create the 'child_image' folder as suggested earlier and place your 'mcuboot.conf' file in this folder. The file will then be picked up by the build system the next time you perform a pristine build.

  • Thanks so much for your help, Vidar! Your suggestion of putting mcuboot.conf into the child_image directory and modifying mcuboot/boot/zephyr/main.c worked perfectly.

    A little correction: The compiler complained that boot_serial_check_start() was given too few arguments. Actually, boot_serial_check_start(&boot_funcs,timeout_in_ms) had to be called, and the definition of timeout_in_ms had to be moved before the call.

    Now, I'm only puzzled about how to integrate the modified mcuboot into my project. My best idea is forking https://github.com/nrfconnect/sdk-mcuboot on GitHub and adding my fork to west.yml to override the stock mcuboot repo. Do you know of a better way?

  • I'm glad to hear that it worked.

    mlac said:
    Now, I'm only puzzled about how to integrate the modified mcuboot into my project. My best idea is forking https://github.com/nrfconnect/sdk-mcuboot on GitHub and adding my fork to west.yml to override the stock mcuboot repo. Do you know of a better way?

    Creating a fork might be the more appropriate way to handle this. However, I would likely have opted for creating a local patch that I apply manually with each new release. A third option is to submit a PR to propose this change upstream.

  • For some reason, I believed that the suggested MCUboot modification worked, but when testing it again, I realized that the bootloader still always timeouts, not only when the board has been hardware-reset.

    I'm surprised that there's no relevant MCUboot option because my use case shouldn't be unusual; I want the board to boot up as quickly as possible, but I also want to be able to manually trigger the bootloader even if the application firmware is broken. There are plenty of unanswered issues and pull requests in the MCUboot repo, so my hopes are not high, but I'll open an issue nevertheless.

    Do you have further ideas for achieving what I'm after? If my goal requires custom development that is outside the scope of this support, I understand. I can probably figure this out, but it may be time-consuming. Alternatively, I'd be glad to pay to get this done.

Related