This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

MCUBoot nRF52840 NCS v1.5.0 - stuck in bootloader

I'm finding that the MCUBoot stays stuck in bootloader mode sometimes when using a CONFIG_BOOT_SERIAL_DETECT_PORT. 

I've narrowed it down to setting up the GPIO as input/pull-up and reading it being the next immediate operation - there are old posts  outlining this could be an issue in nRF52 - i.e. can't read a pin immediately after it was pulled up and expect to get a high.

I'm using an nRF52840DK, PCA10056 v1.0.0   2018.17. Not sure if this is a silicon/DK issue or across the board with nRF52.

Using GPIO0 pin 12 (Button 2 on nRF52840dk)

    /* The default presence value is 0 which would normally be
     * active-low, but historically the raw value was checked so we'll
     * use the raw interface.
     */
    rc = gpio_pin_configure(detect_port, CONFIG_BOOT_SERIAL_DETECT_PIN,
#ifdef GPIO_INPUT
                            GPIO_INPUT | GPIO_PULL_UP
#else
                            GPIO_DIR_IN | GPIO_PUD_PULL_UP
#endif
           );
    __ASSERT(rc == 0, "Error of boot detect pin initialization.\n");

    k_sleep(K_MSEC(10));
#ifdef GPIO_INPUT
    rc = gpio_pin_get_raw(detect_port, CONFIG_BOOT_SERIAL_DETECT_PIN);
    detect_value = rc;
    BOOT_LOG_INF("det pin = %u rc = %u", CONFIG_BOOT_SERIAL_DETECT_PIN, detect_value);

The snippet above is from: ncs/bootloader/mcuboot/boot/zephyr/main.c

As you can see I added a k_sleep() betweeen the GPIO calls _configure() and _get_raw() and that seems to have eliminated the issue.

I'd appreciate if anyone else can confirm the issue or provide a better fix.

MCUBoot config file attached.

mcuboot.conf

Thanks,
FJ

Parents
  • Thanks for the reply and explaining the root cause Hakon.

    Adding a debounce routine as you mentioned would be great.

    But more importantly I think the NCS fork of MCUboot needs to be patched with a delay or your suggested line of code to read a random event register.

    Otherwise you'll have units that use MCUBoot as bootloader with the button method lockup (if reset or pwr cycled) and stay in boot waiting for FW update (though there must be a timeout?).

  • Hi,

    Farhang said:
    But more importantly I think the NCS fork of MCUboot needs to be patched with a delay or your suggested line of code to read a random event register.

    I agree with you 100 %. This is the reason why I reported this internally as bug, and made the mcuboot/bootloader teams aware of this issue.

     

    Kind regards,

    Håkon

Reply Children
No Data
Related