Hello,
I'm experiencing an issue where RTT logs stop appearing after MCUboot jumps to the application on nRF52832. The application is running correctly (BLE advertising and SMP service are visible), but RTT Viewer cannot capture application logs.
### Environment
- **SDK**: nRF Connect SDK v2.5.1
- **Bootloader**: MCUboot (enabled via `CONFIG_BOOTLOADER_MCUBOOT=y`)
- **Application**: Custom application with MCUMGR BLE transport for DFU
### Problem Description
1. **MCUboot logs are visible**: RTT Viewer successfully captures MCUboot startup logs:
```
*** Booting nRF Connect SDK v2.5.1 ***
[00:00:00.xxx] <inf> mcuboot: Starting bootloader
[00:00:00.xxx] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.xxx] <inf> mcuboot: Image index: 0, Swap type: none
[00:00:00.xxx] <inf> mcuboot: Bootloader chainload address offset: 0xc000
[00:00:00.xxx] <inf> mcuboot: Jumping to the first image slot
```
2. **Application logs are NOT visible**: After the jump, RTT Viewer connection remains active (no "Connection lost" message), but logs stop completely. The last log message is:
```
[00:00:00.xxx] <inf> mcuboot: Jumping to the first image slot
```
After this, no application logs appear, even though:
- BLE advertising is working (confirmed via nRF Connect Desktop)
- SMP service is visible and functional
- Application is running (confirmed by BLE connectivity)
- RTT connection is still active (not disconnected)
3. **RTT Viewer behavior**:
- RTT connection remains active after MCUboot jump (no automatic disconnection)
- Logs simply stop appearing after "Jumping to the first image slot"
- No application logs (`printk` or `LOG_INF`) are captured
- If I manually disconnect and reconnect RTT Viewer, it only shows MCUboot logs again
- The RTT connection itself is fine, but the application is not outputting logs to RTT
### Configuration
**Application `prj.conf`:**
```kconfig
# RTT Configuration
CONFIG_USE_SEGGER_RTT=y
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=8192
CONFIG_SEGGER_RTT_BUFFER_SIZE_DOWN=16
CONFIG_SEGGER_RTT_MODE_NO_BLOCK_SKIP=y
CONFIG_RTT_CONSOLE=y
# Logging Configuration
CONFIG_LOG=y
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_LOG_BUFFER_SIZE=8192
CONFIG_LOG_DEFAULT_LEVEL=3
CONFIG_LOG_MAX_LEVEL=4
CONFIG_LOG_PRINTK=y
# RTT Log Backend
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_RTT_MODE_DROP=y
CONFIG_LOG_BACKEND_RTT_OUTPUT_BUFFER_SIZE=8192
CONFIG_LOG_BACKEND_RTT_BUFFER_SIZE=8192
# UART Log Backend (backup)
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_BACKEND_UART_OUTPUT_TEXT=y
CONFIG_UART_CONSOLE=y
# MCUboot Configuration
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_IMG_MANAGER=y
CONFIG_MCUMGR=y
CONFIG_MCUMGR_TRANSPORT_BT=y
```
**MCUboot `child_image/mcuboot.conf`:**
```kconfig
# RTT Configuration (matching application)
CONFIG_USE_SEGGER_RTT=y
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=8192
CONFIG_SEGGER_RTT_BUFFER_SIZE_DOWN=16
CONFIG_SEGGER_RTT_MODE_NO_BLOCK_SKIP=y
CONFIG_RTT_CONSOLE=y
# Logging Configuration
CONFIG_LOG=y
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_RTT_MODE_DROP=y
CONFIG_LOG_BACKEND_RTT_OUTPUT_BUFFER_SIZE=8192
CONFIG_LOG_BACKEND_RTT_BUFFER_SIZE=8192
# MCUboot Configuration
CONFIG_BOOT_BANNER=y
CONFIG_BOOT_SWAP_USING_MOVE=y
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE=""
```
### Application Code
The application uses both `printk` and `LOG_INF` for logging:
```c
int main(void)
{
// Early printk statements
printk("\n\n");
printk("========================================\n");
printk("DFU Test1 - MAIN STARTED\n");
printk("MCUboot jumped to application\n");
printk("Address: 0x%08x\n", (uint32_t)main);
printk("========================================\n");
// Multiple printk statements to ensure visibility
for (int i = 0; i < 10; i++) {
printk("[MAIN] Starting... %d\n", i);
k_sleep(K_MSEC(50));
}
k_sleep(K_MSEC(500));
// LOG_INF statements
LOG_INF("========================================");
LOG_INF("DFU Test1 - Starting");
LOG_INF("========================================");
// ... BLE initialization ...
// Worker thread with periodic logging
// (logs every 5 seconds using both printk and LOG_INF)
return 0;
}
### What I've Tried
1. 
**Ensured RTT configuration consistency**: Both MCUboot and application use identical RTT buffer sizes and modes
**Ensured RTT configuration consistency**: Both MCUboot and application use identical RTT buffer sizes and modes2. **Added `CONFIG_RTT_CONSOLE=y`**: To ensure `printk` uses RTT instead of UART
**Added `CONFIG_RTT_CONSOLE=y`**: To ensure `printk` uses RTT instead of UART3. **Increased RTT buffer sizes**: Set to 8192 bytes for both MCUboot and application
**Increased RTT buffer sizes**: Set to 8192 bytes for both MCUboot and application4. **Used `CONFIG_LOG_MODE_IMMEDIATE=y`**: To ensure logs are output immediately
**Used `CONFIG_LOG_MODE_IMMEDIATE=y`**: To ensure logs are output immediately5. **Added `CONFIG_LOG_PRINTK=y`**: To ensure `printk` messages are captured
**Added `CONFIG_LOG_PRINTK=y`**: To ensure `printk` messages are captured6. **Used both `printk` and `LOG_INF`**: To test both logging mechanisms
**Used both `printk` and `LOG_INF`**: To test both logging mechanisms7. **Added worker thread**: To continuously output logs every 5 seconds
**Added worker thread**: To continuously output logs every 5 seconds8. **Reset device immediately after flashing**: `nrfjprog --reset`
**Reset device immediately after flashing**: `nrfjprog --reset`9. **Tried reconnecting RTT Viewer**: After waiting 10-15 seconds
**Tried reconnecting RTT Viewer**: After waiting 10-15 seconds### Observations
- The official Zephyr SMP Server example (`zephyr/samples/subsys/mgmt/mcumgr/smp_svr`) disables RTT for nRF52832 (`CONFIG_USE_SEGGER_RTT=n` in `boards/nrf52dk_nrf52832.conf`), likely to save Flash space
- However, I need RTT logging for development and debugging
- The application is definitely running (BLE works), but RTT logs are not captured
### Questions
1. **Is RTT logging supported after MCUboot jump on nRF52832?** Or is this a known limitation?
2. **Why would RTT connection remain active but logs stop appearing?** The connection is fine, but the application doesn't output logs to RTT.
3. **Should RTT control block addresses be the same for MCUboot and application?** How can I verify/configure this? Could different RTT control block addresses cause logs to stop?
4. **Are there any specific memory layout requirements** for RTT to work correctly with MCUboot? Does MCUboot jump reset or relocate the RTT control block?
5. **Is there a recommended configuration** for RTT logging with MCUboot on nRF52832?
6. **Has anyone successfully used RTT logging with MCUboot on nRF52832?** If so, what configuration did you use?
7. **Could the application's RTT initialization be failing silently?** How can I verify if RTT is properly initialized in the application?
Any guidance or suggestions would be greatly appreciated!
Thank you
