Standalone app runs but adding MCUboot kills all serial output

[Dave Littell]

Environment: SDK v3.1.1 with a custom board based on the nRF52840.

I wrote a test application that I've been using to verify the hardware on a custom nRF52840 board.  I have a DTS overlay and code in place to test the interfaces, GPIO's, etc. that we'll be using on the board.  The idea was to use this known-working test app as the basis for a minimal app to which MCUboot and application-level DFU would be added.  (There's no need for the Serial Recovery feature in this effort, only application-based dual-slot DFU with a non-UART transport - the app guys will implement that later.)  So I left the test app's DTS overlay in place along with all the needed interfaces enabled in prj.conf and just pared down the code to print a "Hello World" to the Console UART.  That worked fine on the board when built as a standalone app.  I then attempted to follow the DevAcademy Intermediate Lesson 9 Exercise 1 to simply enable MCUboot.  Step 1, add a sysbuild.conf:

# Enable MCUboot:
SB_CONFIG_BOOTLOADER_MCUBOOT=y

# DFU from the application requires two slots:
SB_CONFIG_MCUBOOT_MODE_SINGLE_APP=n

Step 2, add a sysbuild/mcuboot.conf:

# Disable Serial Recovery:
CONFIG_MCUBOOT_SERIAL=n

# Enable UART console for MCUboot:
CONFIG_UART_CONSOLE=y
CONFIG_SERIAL=y

# Enable MCUboot logging:
CONFIG_LOG=y
CONFIG_MCUBOOT_LOG_LEVEL_INF=y

Just build and run, right?  Nope - there's no output on the Console UART as shown in Lesson 9 Exercise 1's startup banners.  Now I'm wondering if there's something in the app's prj.conf that's interfering with MCUboot?  (Remember the app worked just fine as a standalone image wi/no MCUboot.)  Here's the app's prj.conf:

#
# This is required because the nRF52840 appears to default to requiring an external low-speed
# clock to get going.  These settings tell it to use it's internal RC instead (which *should*
# be the default!)
#
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n

CONFIG_GPIO=y

CONFIG_SERIAL=y

CONFIG_I2C=y

CONFIG_SPI=y
CONFIG_SPI_NOR=n  # TODO FIXME disabled to get past some "compatible" problem with the SPI1 DTS overlay.

CONFIG_PWM=y

CONFIG_ADC=y

# Enable USB HID device support for board test purposes
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_HID=y
CONFIG_USB_DEVICE_PRODUCT="Zephyr HID mouse sample"
CONFIG_USB_DEVICE_PID=0x0007
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n


# Enable mcumgr DFU in the app:
# Enable MCUMGR 
CONFIG_MCUMGR=y

# Enable MCUMGR management for both OS and Images
CONFIG_MCUMGR_GRP_OS=y
CONFIG_MCUMGR_GRP_IMG=y

# Configure MCUMGR transport via UART (disable - image transport will be added later)
CONFIG_MCUMGR_TRANSPORT_UART=n

# Dependencies
# Configure dependencies for CONFIG_MCUMGR  
CONFIG_NET_BUF=y
CONFIG_ZCBOR=y
CONFIG_CRC=y

# Configure dependencies for CONFIG_MCUMGR_GRP_IMG  
CONFIG_FLASH=y
CONFIG_IMG_MANAGER=y

# Configure dependencies for CONFIG_IMG_MANAGER  
CONFIG_STREAM_FLASH=y
CONFIG_FLASH_MAP=y

# Configure dependencies for CONFIG_MCUMGR_TRANSPORT_UART 
CONFIG_BASE64=n

Nothing I've tried produces either the MCUboot or the application startup banners shown in Lesson 9 Exercise 1.  I can only guess that I've misconfigured something but I can't imagine what.  I didn't include the DTS overlay in this query but can certainly add it if it would be helpful.

Thanks very much,

Dave

[Vidar Berg]

Hello Dave,

It seems like you are only selecting the RC oscillator as your LF clock source for your application, but not in the bootloader. This means the bootloader will default to using the crystal oscillator, and if the crystal is not mounted on the board, then the bootloader will enter an infinite loop waiting on the crystal to ramp up.  Please try to add CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to your mcuboot configuration in sysbuild/mcuboot.conf and see if that helps. Do make the RC oscillator the default for all projects you can define your own board (assuming you are currently using the nrf52840dk as your build target).

Best regards,

Vidar 

[Dave Littell]

Hi Vidar!  Thanks very much for the quick reply.  Adding that line to mcuboot.conf did seem to help but something's still not quite right.  Here's the output following a reset.  (Note that no output appears if the board is power-cycled, it must be reset to print anything.  Also, resets are now unreliable - sometimes they work, sometimes they fail.  This wasn't the case before incorporating MCUBoot.)

Hello World from CMAKE_SOURCE_DIR/src/main.c::main()!
[00:00:00.000,335] <err> ADT7310: Invalid device ID
[00:00:00.000,549] <err> ADT7310: Invalid device ID
*** Booting My Application v0.1.0 - unknown commit ***
*** Using nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***

There's a few problems with this output.  First, I expected some startup banner and output from MCUBoot similar to what's shown in Intermediate Lesson 9 Exercise 1.  Second, the output from the application itself ("Hello World ...") occurs before the "Booting My Application ..." and "Using nRF Connect ..." banners.  Third, the application just prints its "Hello World ..." at 1Hz in a loop.  No more output occurs after the "Using nRF Connect ..." banner.

Also, from reset to reset the output may differ.  Sometimes the "*** ..." banner lines complete as shown but other times only a portion appears.

Dave

[Vidar Berg]

Hi Dave,

Happy to help! You mentioned having a DTS overlay for your application, does this overlay change the default UART pinout to match your hardware by any chance? As with the clock configuration, the DT overlay for the application will not be automatically applied to the MCUboot build. If you need to modify the pin assignments in the bootloader to get log output, you can create a file named mcuboot.overlay in your sysbuild directory.
(Note: A pristine build is required after adding a new file to the sysbuild folder)

Best regards,

Vidar

[Dave Littell]

Ah!  The Magic!  My hardware designers took liberties and changed a few things relative to the DK.  Those changes have cost us time and again.  Creating the mcuboot.overlay seems to have made all the difference.  There are a couple of things I noticed in the output:

*** Booting MCUboot v2.1.0-dev-9b4ae4cbc9e2 ***
*** Using nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0xc000
I: Image version: v0.1.0
▒Hello World from CMAKE_SOURCE_DIR/src/main.c::main()!
[00:00:00.000,305] <err> qspi_nor: JEDEC id [ff ff ff] expect [c2 28 17]
*** Booting My Application v0.1.0 - unknown commit ***
*** Using nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
Hello World from CMAKE_SOURCE_DIR/src/main.c::main()!
Hello World from CMAKE_SOURCE_DIR/src/main.c::main()!
Hello World from CMAKE_SOURCE_DIR/src/main.c::main()!
Hello World from CMAKE_SOURCE_DIR/src/main.c::main()!

Everything looks good except for the couple of lines following the "Image version: ...".  Is the first "Hello World" an artifact of the logging versus the printf() timing in the app's main()?  Next, the error log from qspi_nor is unexpected as I explicitly disabled qspi in the app's DTS overlay, so it shouldn't be probing the QSPI NOR device, right?

(As a suggestion, maybe Intermediate Lesson 9 could be improved to highlight that MCUboot needs the same config and DTS overlay changes that might have been done in the app.)