Standalone app runs but adding MCUboot kills all serial output

RE: Standalone app runs but adding MCUboot kills all serial output

Dave Littell — Thu, 04 Dec 2025 15:07:57 GMT

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.)

RE: Standalone app runs but adding MCUboot kills all serial output

Vidar Berg — Thu, 04 Dec 2025 07:43:05 GMT

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

RE: Standalone app runs but adding MCUboot kills all serial output

Dave Littell — Wed, 03 Dec 2025 15:42:40 GMT

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

RE: Standalone app runs but adding MCUboot kills all serial output

Vidar Berg — Wed, 03 Dec 2025 14:10:48 GMT

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