MCUBoot configuration on nRF528240: Can't get out of bootload mode

[cscase]

Hi all,

I am trying to use MCUBoot on the nRF52840, and am having troubles with this: Whenever my device boots, it always immediately goes to bootload mode and I can't get application code to run.

Ultimately, I want to use this on my own hardware with my own code, but for simplicity's sake, I am currently troubleshooting it with a modified blinky sketch and using the nRF52840-DK to remove as many variables as possible.

I am using NCS 2.6.1, with the nRF52840-DK.

Here is the code I am using:

https://github.com/blues/note-outboard-dfu/tree/main/nrf52840/blinky/ncs/fast

This example project is intended to demonstrate an integration with another vendor's hardware, but at present I'm just trying to get the bootloader to work, with no connection to any external hardware, on the DK board.

Symptom: Any time the device boots, it goes immediately into bootloader mode. (The intent is that bootloader mode would be triggered only when a specific GPIO is asserted.)

There are a couple of config files for mcuboot: an overlay and an mcuboot.conf. Here's what is in the overlay:

/ {

    buttons {
        compatible = "gpio-keys";
        buttonDFU: button_dfu {
            gpios = <&gpio0 10 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
            label = "DFU activation button";
        };
    };


    aliases {
        mcuboot-led0 = &led0;
//      mcuboot-button0 = &button0; // to use the onboard button on the Adafruit nRF52840 Feather Express

        // use the pin defined above to enter boot mode.
        mcuboot-button0 = &buttonDFU;
    };
};

And the mcuboot.conf:

# After creating your own key pair, uncomment this config value to set the path of the private key
CONFIG_BOOT_SIGNATURE_TYPE_RSA=y

CONFIG_SIZE_OPTIMIZATIONS=y

# This provides more space for the application.
# Since the Notecard is able to send firmware to a device without a working app,
# there is no need for the redundancy of multiple application slots.
CONFIG_SINGLE_APPLICATION_SLOT=y

# Validate the image in slot 0 before executing
CONFIG_BOOT_VALIDATE_SLOT0=y

# Enable MCUboot Serial Recovery
CONFIG_MCUBOOT_SERIAL=y

# Disable the UART console (not compatible with CONFIG_MCUBOOT_SERIAL=y)
CONFIG_UART_CONSOLE=n

# enable the echo command, used for testing connectivity
CONFIG_BOOT_MGMT_ECHO=y

#
# Options below this point may be edited.
#

# Helpful during testing to show that MCUBoot is active
# May be set to `n` in a deployed product to save power during device updates
CONFIG_MCUBOOT_INDICATION_LED=y

# Wait for DFU - useful in cases where AUX3 is not physically connected to any boot pin.
# You can comment these lines out when using a boot pin
#CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=y

# How long to wait for a request over UART
# You can increase this value, but decreasing it may lead to the device not entering bootloader mode.
# CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=300


#
# These configuration options were useful during development
#

# Perform a debug build
# CONFIG_DEBUG=y

# Add logging
# CONFIG_LOG=y
# Enable logging over RTT
# CONFIG_RTT_CONSOLE=y
# CONFIG_USE_SEGGER_RTT=y
# CONFIG_LOG_BACKEND_RTT=y
# CONFIG_LOG_MODE_MINIMAL=n
# CONFIG_MULTITHREADING=y # required for RTT logging
# CONFIG_MCUBOOT_UTIL_LOG_LEVEL_DBG=y
# CONFIG_LOG_DEFAULT_LEVEL=4

What would be a good way to approach troubleshooting this? How can I determine what the cause is of the "false positive" bootloader trigger?

Thanks for any insights you may be able to share.

Scott

P.S. I did read the other post here on DevZone titled 'MCUBoot nRF52840 NCS v1.5.0 - stuck in bootloader.'  In that post, someone writes about an issue stemming from sampling the GPIO too quickly after it is configured, and he resolved it by adding a delay in the bootloader code. I looked at the file in question, and clearly in the time since that post was written, mcuboot has been improved in this area and nowadays it checks for ready state on the GPIO and debounces it. So I don't think the issue referenced in that post is what I am running into today, but I'm certainly open to correction if I've reached an incorrect conclusion there.

[cscase]

I think I found a solution for this: The setup is trying to use P0.10 to trigger bootloader. However, that pin by default is used for NFC. I need to include the following in my devicetree overlay to make it work right:

    &uicr {

        nfct-pins-as-gpios;

    };