Setting CONFIG_BOOTLOADER_MCUBOOT=y in prj.config on custom board prevents code working

[Mike Austin (LPI)]

I've been doing all my pre-production coding under the following environment:

• Visual Studio Code v1.71.2, with nRF Connect Extension (v2022.9.179)
• nRF Connect SDK v2.0.0
• nRF52-DK

I've got my code running successfully under the above arrangement.  Recently, I tried porting this to my custom board, which uses the same IC as the nRF52-DK, which is the nRF52832.  I've been able to successfully program this with some simple LED Blinky and System_Off examples I had generated in the earlier days of development with the nRF52-DK, and everything appears to work as expected.

However, when I go to flash my pre-production code, that works on the nRF52-DK, then nothing works.

I've isolated this to the setting of CONFIG_BOOTLOADER_MCUBOOT=y in my prj.config file.  I can't just comment this out of my pre-production code, as it causes all sorts of other issues, but if I copy my working code prj.config file to, say, my LED_Blinky code, then I see the following:

• CONFIG_BOOTLOADER_MCUBOOT=y then the code won't run
• CONFIG_BOOTLOADER_MCUBOOT=n, then the code runs

I'm trying to understand why, even though the IC's on both the nRF52-Dk and my custom board are exactly the same, that trying to enable mcuboot on my custom board is causing me issues.

Ultimately, I need mcuboot as I am including OTA DFU functionality in my final design

Anyone seen this issue before and know how I can go about resolving it?

CHeers,

Mike

[Mike Austin (LPI)]

Hi Sigurd,

No, im not using the DC-DC converter so have set the appropriate CONFIG = n for that.

And yes, I’ve got both the 32MHz HFXO and 32.768kHz LFXO.

There’s some more detail on my custom board here:

devzone.nordicsemi.com/.../issues-with-programming-operation-of-custom-pcb-with-nrf52832

Cheers,

Mike

[Sigurd Hellesvik]

Hi Mike,

Some project configurations can be overwritten by child images. This is what I suspect happens in this case.

Can you post your prj.conf for your project + configurations for your custom boards, and I will see if I can find anything that seems off.

Regards,
Sigurd Hellesvik

[Mike Austin (LPI)]

Hi Sigurd,

Below is the prj.conf and the overlay file I am using.  Note that I am using this exact same set up for the nRF52-DK as well as for my custom board, as essentially I've used the same GPIO, etc on my custom board as I was using on the nRF52-DK.

# General
CONFIG_REBOOT=y
#CONFIG_BT_DEBUG_CONN=y
#CONFIG_DEBUG_ATT=y
#CONFIG_BT_DEBUG_GATT=y
CONFIG_GPIO=y
CONFIG_BOARD_ENABLE_DCDC=n

# Logging
#CONFIG_LOG=y
#CONFIG_LOG_MODE_MINIMAL=y
#CONFIG_BT_DEBUG_LOG=y

# UART
#CONFIG_SERIAL=y
#CONFIG_UART_INTERRUPT_DRIVEN=y

#Device Name - will be visible to clients scanning
CONFIG_BT_DEVICE_NAME="LSRMAX_9"

# Bluetooth
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_SMP=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_GATT_DM=y
CONFIG_BT_MAX_PAIRED=10
CONFIG_BT_KEYS_OVERWRITE_OLDEST=y

# Allow for large Bluetooth data packets.
CONFIG_BT_L2CAP_TX_MTU=498
CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_BUF_ACL_TX_SIZE=502
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

# Enable CTS client
CONFIG_BT_CTS_CLIENT=y

# Below is setup to let DIS information be read from settings
CONFIG_BT_SETTINGS=y
CONFIG_SETTINGS_RUNTIME=y
CONFIG_SETTINGS=y

# Enable mcumgr.
CONFIG_MCUMGR=y

# Enable most core commands.
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y

# Enable the Bluetooth (unauthenticated) and shell mcumgr transports.
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL=y

# Enable the mcumgr Packet Reassembly feature over Bluetooth and its configuration dependencies.
# MCUmgr buffer size is optimized to fit one SMP packet divided into five Bluetooth Write Commands,
# transmitted with the maximum possible MTU value: 498 bytes.
CONFIG_MCUMGR_SMP_REASSEMBLY_BT=y
CONFIG_MCUMGR_BUF_SIZE=2475
CONFIG_OS_MGMT_MCUMGR_PARAMS=y


# Some command handlers require a large stack.
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=6144
CONFIG_HEAP_MEM_POOL_SIZE=1024

# Allow flash
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
#CONFIG_NVS_LOG_LEVEL_DBG=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y

# Enable Power Management
CONFIG_PM=y

# Required to disable default behavior of deep sleep on timeout
CONFIG_PM_DEVICE=y

# Optional select RAM retention (nRF52 only)
#CONFIG_APP_RETENTION=y

# Enable I2C
CONFIG_I2C=y
CONFIG_COUNTER=y
CONFIG_PCF85063A=y

# fs_dirent structures are big.
CONFIG_MAIN_STACK_SIZE=4096

# Enable file system
CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_LITTLEFS=y
CONFIG_MCUMGR_CMD_FS_MGMT=y

# Enable JSON formatting
CONFIG_JSON_LIBRARY=y

/ {

mypins {
    compatible = "gpio-keys";
    pinA: gpio_in_A {
        gpios = <&gpio0 22 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH) >;
        label = "Power Up Device";
    };
    pinB: gpio_in_B {
        gpios = <&gpio0 12 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>;
        label = "Factory Mode Enable";
    };
    pinC: gpio_in_C {
        gpios = <&gpio0 13 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
        label = "Small Strike";
    };
    pinD: gpio_in_D {
        gpios = <&gpio0 14 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
        label = "Medium Strike";
    };
    pinE: gpio_in_E {
        gpios = <&gpio0 15 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
        label = "Large Strike";
    };
    
};

aliases {
    pina = &pinA;
    pinb = &pinB;
    pinc = &pinC;
    pind = &pinD;
    pine = &pinE;
    };

};

&i2c0 {
    pcf85063a@51 {
        compatible = "nxp,pcf85063a";
        reg = <0x51>;
        label = "PCF85063A";
    };
};

When I do a build, I select nrf52dk_nrf52832 as the board.

When I flash the code to the DK, it works.  When I flash the exact same code to the custom board, I appear to get nothing happening.  I did try running Ozone to debug the code when its on the custom board, and I can in fact see it go through the code the first time around after programming.  My code is essentially using the System_Off mode, and is supposed to exit this on detection of a signal on any number of GPIO.  Of course, when its first flashed, it gets issued a software reset and during debugging, I can see that occur and my code will run through.  But if I then try and trigger it again with a GPIO signal I see nothing.

Under normal operation, without debugging, I see no activity whatsoever, based on monitoring the nRF Terminal output (I'm outputting a bunch of printk() statements to debug when my code is running in real time)

When I first saw that, I went back to some basic code I had written earlier in the development, and when I flash that to the custom board, it seemed to work.  That code was initially just a LED_Blinky, then I added System_Off functionality.  That all worked well on the custom board.

So, I figured it must be some configuration that was causing the issue.  That's when I copied the prf.conf file from my full code (that works on the DK) into my LED_Blinky code, and noticed that stopped working on my custom board.  So I just commented parts of the prf.conf file out until the custom board started working with the LED_Blinky code, and noticed it was the:

CONFIG_BOOTLOADER_MCUBOOT=y

that was causing things to stop working.

That may not be the true issue here, so just letting you know my fault-finding process, in case I've led you on a wild goose chase.

Cheers,

Mike

[Sigurd Hellesvik]

Hi Mike,

Mike Austin (LPI) said:

No, im not using the DC-DC converter so have set the appropriate CONFIG = n for that.

Create a folder in your project called child_image.
Then create the file child_image/mcuboot.conf.
Set the relevant configurations to disable DC-DC inside this mcuboot.conf as well.

Does this change anything?

Regards,
Sigurd Hellesvik

[Mike Austin (LPI)]

Hi Sigurd,

Bingo!  That fixed it.  Makes sense too.  I already had the mcuboot.conf as I had to create that to turn off GPIO during mcuboot, as it was clearing out my LATCH register before I had a change to see which GPIO was brining the device out of sleep mode.

Makes sense that I'd need to disable the DC-DC in both the mcuboot.conf and prf.conf files.

Thanks for your help

Cheers,

Mike

[thang47]

Hi Austin,

I have same the problem, can you help me?

[Mike Austin (LPI)]

I had to set CONFIG_ENABLE_DC_DC=n in BOTH my proj.conf and my mcuboot.conf files to solve the issue for my custom board as I wasn’t using the DC DC converter feature that is enabled on the DK

Mike