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
  • Hi,

     

    Since the cpu runs on 64 MHz, and the peripheral interface is on 16M, writes and immediate reads need to be sync'ed towards the slowest clock, which is the peripheral clock here. Reading any random event register will generate a wait condition if required, for instance (void)NRF_TIMER0->EVENTS_COMPARE[0];.

    I agree that the non-existing debounce routine here can be highly improved. I'll report this internally as a bug. Thank you for reporting this back to us!

     

    Kind regards,

    Håkon

Reply
  • Hi,

     

    Since the cpu runs on 64 MHz, and the peripheral interface is on 16M, writes and immediate reads need to be sync'ed towards the slowest clock, which is the peripheral clock here. Reading any random event register will generate a wait condition if required, for instance (void)NRF_TIMER0->EVENTS_COMPARE[0];.

    I agree that the non-existing debounce routine here can be highly improved. I'll report this internally as a bug. Thank you for reporting this back to us!

     

    Kind regards,

    Håkon

Children
No Data
Related