B0 secure bootloader logging with RTT not working.

Question

Hi, 
 I’m facing an issue with RTT logging on my nRF52840 using NCS 2.6.0. I’m trying to log output from the B0 bootloader, but so far, I’m only able to capture logs from the application and the MCUboot. 
 I want to verify the MCUbootloader version, and as I understand it, I need to log output from B0 as described in the example: https://docs.nordicsemi.com/bundle/ncs-2.6.0/page/nrf/config_and_build/bootloaders/bootloader_testing.html b0.conf: 
 # Marks this image as B0
CONFIG_IS_SECURE_BOOTLOADER=y

CONFIG_FW_INFO=y

# Disables multithreading — B0 runs in a single-threaded mode (smaller + simpler).
CONFIG_MULTITHREADING=n

CONFIG_GPIO=n
CONFIG_ASSERT=n

# Enables Nordic's Flash Protect driver — used by B0 to lock flash regions after boot.
#CONFIG_FPROTECT=y

# Enables cryptographic support for signature verification 
CONFIG_SECURE_BOOT_CRYPTO=y
# Enables validation of second-stage bootloader (MCUboot) via signature check.
CONFIG_SECURE_BOOT_VALIDATION=y

# Enables debug logging in B0 (useful for RTT/UART messages during boot).
CONFIG_SECURE_BOOT_DEBUG=y
#CONFIG_SECURE_BOOT_DEBUG_BACKEND=y

# Enable RTT logging in B0
CONFIG_SECURE_BOOT_DEBUG_RTT=y 
CONFIG_SECURE_BOOT_DEBUG_UART=n # (alternative: UART debug)


CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_LOG_MODE_MINIMAL=n

CONFIG_SECURE_BOOT_STORAGE=y

# Enables direct access to flash controller (NVMC) — needed for version storage, fprotect
CONFIG_NRFX_NVMC=y

# Sets stack size for B0's main thread (typically 1024–2048 is fine).
CONFIG_MAIN_STACK_SIZE=2048

# Set internal RC oscillator
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

# Avoid triggering IRQs from the RTC
CONFIG_NRF_RTC_TIMER=n 
 mcuboot.conf: 
 # Bootloader version (monotonic counter for B0). Must increment on updates.
CONFIG_FW_INFO=y
CONFIG_FW_INFO_FIRMWARE_VERSION=1

# Signature Type: RSA
CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
CONFIG_BOOT_SIGNATURE_TYPE_RSA_LEN=2048

# Application update procedure
CONFIG_BOOT_UPGRADE_ONLY=y
#CONFIG_BOOT_SWAP_USING_SCRATCH=y

# Enable Multithreading. Required for RC calibration
CONFIG_MULTITHREADING=y

# Debug
CONFIG_MCUBOOT_LOG_LEVEL_INF=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_CONSOLE=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_CONSOLE_HANDLER=n

# Set internal RC oscillator
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

# External Flash Support
CONFIG_NRFX_SPIM2=y
CONFIG_FLASH=y
CONFIG_AT25XE081_FLASH_DRIVER=y
CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y

# For nRF52840, increase max supported image size
CONFIG_BOOT_MAX_IMG_SECTORS=256 
 Relevant prj.conf: 
 # --------------------------------------------------------------------
# ------------------------------------------------------- Bootloader --
# - Enables the immutable bootloader (NSIB)
CONFIG_SECURE_BOOT=y
# - Adds MCUboot as an upgradable second-stage bootloader
CONFIG_BOOTLOADER_MCUBOOT=y
# - Enable second slot (S1) for MCUboot for OTA bootloader update
CONFIG_BUILD_S1_VARIANT=y
# - Include firmware info metadata (required for B0 chain) 
CONFIG_FW_INFO=y 
 
 EDIT: When I erase the chip and flash only b0_container.hex , I get the following log output: 
 *** Booting nRF Connect SDK v3.5.99-ncs1 ***
Attempting to boot slot 0.
No fw_info struct found.
Attempting to boot slot 1.
No fw_info struct found.
No bootable image found. Aborting boot.
 
 This makes sense, since there’s no valid image yet. However, when I then flash the signed_by_mcuboot_and_b0_s0_image_signed.hex , I only see MCUboot logging output — the B0 logging no longer appears: 
 00> Device: XXX, HW Rev: UNKNOWN, Platform #: -1
00> -- Bootloader Firmware -- 
00> Firmware Version: 3.13.0
00> Firmware Build Time: May 5 2025 13:44:57
00> * SPI Flash ID: 17951 *
00> *** Booting nRF Connect SDK v3.5.99-ncs1 ***
00> I: Starting bootloader
00> I: Image index: 0, Swap type: perm
00> E: Unable to find bootable image 
 
 PS: Debugging MCUboot is also a bit tricky — sometimes it works if I reconnect the debugger at exactly the right moment (immediately after power-up), but other times it doesn’t work at all. 
 BR Daniel

Edvin · Accepted Answer

Hello, 
 Do you have any other application images using RTT Logging? The application or the "normal" MCUBOOT bootloader? It appears that you do: 
 signed_by_mcuboot_and_b0_s0_image_signed.hex , I only see MCUboot logging output 
 The challenge is that RTT logging is only a buffer somewhere in RAM. When you jump from one image to the next, e.g. from mcuboot to application, then this RAM may be re-used. So depending on when the RTT terminal tries to access the RTT buffer, it may or may not be overwritten. Since the B0 bootloader is so small, it probably will be overwritten very quickly once the MCUBOOT bootloader and later application is taking control. 
 One workaround could be, for debugging purposes, to add a long delay before moving on from the B0 bootloader. And then remove this when you are no longer need to monitor the log from B0. The same applies for MCUBOOT. This will also be quite quickly overwritten by the application. 
 For the B0 bootloader, that would be in the nrf\samples\bootloader\src\main.c, inside validate_and_boot(), right before bl_boot(). 
 Another possible workaround would be to look in the linker script where the RTT buffer is placed, and then set the address in the RTT viewer manually. But note that this may change on every rebuild, so it is kind of a tedious process. 
 
 Best regards, 
 Edvin

B0 secure bootloader logging with RTT not working.

Top Replies